今回は GBDT (Gradient Boosting Decision Tree) フレームワークのひとつである CatBoost について、いくつかの環境で同一のソースコードを使って学習にかかる時間を比較してみた。
きっかけは、最近入手した Apple M2 Pro を搭載した Mac mini が、どれくらいの性能を出せるのか気になったため。
$ head /proc/cpuinfo | grep name
model name : 12th Gen Intel(R) Core(TM) i7-12700
$ uname -srm
Linux 5.15.0-60-generic x86_64
$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=20.04DISTRIB_CODENAME=focal
DISTRIB_DESCRIPTION="Ubuntu 20.04.5 LTS"
なお、最近のデスクトップ向けの CPU は、同じモデルであっても供給する電力によってパフォーマンスが大きく変わってくる。
今回は PBT と MTP の両方に固定で 125W を設定している。
ベンチマークを実行する。
136812 MainThread __main__ INFO start: CatBoost
...
136812 MainThread __main__ INFO end: CatBoost
136812 MainThread __main__ INFO elapsed time: 394.81 sec
こちらは 394 秒かかった。
同じコア構成 (8 Performance Cores + 4 Performance Cores) の Apple M2 Pro と比較して約 26 % 時間が短縮されている。
ただし、Apple M2 Pro の消費電力は最大でも 60W なので約半分という点は留意する必要がある。
>>> test_df = pl.DataFrame({"fruits": ["apple", None, "banana"]})
>>> encoder.transform(test_df)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
...
ValueError: Columns to be encoded can not contain null
encoder = sk.OrdinalEncoder(handle_unknown="error")
encoder.fit(train_df)
test_df = pl.DataFrame({"fruits": ["apple", "blueberry", "banana"]})
>>> encoder.transform(test_df)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
...
ValueError: Columns to be encoded can not contain unknown value
pd_encoder = ce.OrdinalEncoder(cols=["cut", "color", "clarity"])
pd_encoder.fit_transform(pd_df.iloc[:5])
carat cut color clarity depth table price x y z
00.2311161.555.03263.953.982.4310.2121259.861.03263.893.842.3120.2331356.965.03274.054.072.3130.2922462.458.03344.204.232.6340.3133163.358.03354.344.352.75
pd_encoder = ce.CountEncoder(cols=["cut", "color", "clarity"])
pd_encoder.fit_transform(pd_df.iloc[:5])
carat cut color clarity depth table price x y z
00.2313261.555.03263.953.982.4310.2123159.861.03263.893.842.3120.2323156.965.03274.054.072.3130.2921162.458.03344.204.232.6340.3121263.358.03354.344.352.75
%timeit pd_encoder.fit_transform(pd_df)
17.2 s ± 64.2 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
作成した直後はシステムの作成するリソースの準備が整っていないことがある。
そこで kubectl get all サブコマンドなどを使ってシステムのリソースが稼働していることを確認する。
$ kubectl get all -A
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system pod/local-path-provisioner-79f67d76f8-hpcs9 1/1 Running 0 64s
kube-system pod/coredns-597584b69b-n268h 1/1 Running 0 64s
kube-system pod/metrics-server-5f9f776df5-qhzz2 1/1 Running 0 64s
kube-system pod/helm-install-traefik-crd-7m896 0/1 Completed 0 64s
kube-system pod/helm-install-traefik-mnlxz 0/1 Completed 1 64s
kube-system pod/svclb-traefik-07031ac5-j8cx2 2/2 Running 0 36s
kube-system pod/traefik-66c46d954f-qgfh7 1/1 Running 0 36s
NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
default service/kubernetes ClusterIP 10.43.0.1<none>443/TCP 79s
kube-system service/kube-dns ClusterIP 10.43.0.10<none>53/UDP,53/TCP,9153/TCP 76s
kube-system service/metrics-server ClusterIP 10.43.76.82<none>443/TCP 75s
kube-system service/traefik LoadBalancer 10.43.82.71172.18.0.3 80:31992/TCP,443:32477/TCP 36s
NAMESPACE NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
kube-system daemonset.apps/svclb-traefik-07031ac5 11111<none> 36s
NAMESPACE NAME READY UP-TO-DATE AVAILABLE AGE
kube-system deployment.apps/local-path-provisioner 1/111 76s
kube-system deployment.apps/coredns 1/111 76s
kube-system deployment.apps/metrics-server 1/111 75s
kube-system deployment.apps/traefik 1/111 36s
NAMESPACE NAME DESIRED CURRENT READY AGE
kube-system replicaset.apps/local-path-provisioner-79f67d76f8 111 65s
kube-system replicaset.apps/coredns-597584b69b 111 65s
kube-system replicaset.apps/metrics-server-5f9f776df5 111 65s
kube-system replicaset.apps/traefik-66c46d954f 111 36s
NAMESPACE NAME COMPLETIONS DURATION AGE
kube-system job.batch/helm-install-traefik-crd 1/1 32s 74s
kube-system job.batch/helm-install-traefik 1/1 34s 74s
準備が整っていることを確認したらリソースを作成していく。
まずは Pod を作る。
$ kubectl run nginx-pod \--image=nginx\--labels="app=web"
pod/nginx-pod created
$ kubectl get pod
NAME READY STATUS RESTARTS AGE
nginx-pod 1/1 Running 0 11s
続いて Pod に対応する Service を作成する。
Service では nginx-pod の TCP/80 ポートを公開する。
Pod に対応する Service を作るには kubectl expose pod サブコマンドを使うと手っ取り早い。
$ kubectl expose pod nginx-pod \--port80\--protocol TCP \--name nginx-service
service/nginx-service exposed
$ kubectl get service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.43.0.1<none>443/TCP 9m50s
nginx-service ClusterIP 10.43.138.181<none>80/TCP 22s
$ curl -sL http://localhost:8080
<!DOCTYPE html><html><head><title>Welcome to nginx!</title><style>
html { color-scheme: light dark;}
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif;}</style></head><body><h1>Welcome to nginx!</h1><p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p><p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p><p><em>Thank you for using nginx.</em></p></body></html>
ちゃんと Nginx がデフォルトで提供するウェルカムページの内容が得られた。
確認が終わったら作成したリソースを一通り削除して掃除する。
$ kubectl delete ingress nginx-ingress
ingress.networking.k8s.io "nginx-ingress" deleted
$ kubectl delete service nginx-service
service "nginx-service" deleted
$ kubectl delete pod nginx-pod
pod "nginx-pod" deleted
NetworkPolicy リソースを試す
続いては NetworkPolicy リソースを試す。
まずは次のように Pod を 3 つ作成する。
名前やラベルは pod[123] として付けておく。
