8コアノートPCでメモリ64GBにSSDを3TBとか

32GBのSO-DIMMが安定流通したお陰で普通のノートPCにもメモリ64GBが簡単に載るようになってきた。

 

前ネタはこの辺である。3年前の当時は4コアノートPCに総額10万円程度である。

bleu48.hatenablog.com

bleu48.hatenablog.com

 

昨今は公共機関での移動や飲食店などでの作業も激減したため,今回は15インチ級で以下の構成。

一般より低スペックでAmazon専売モデルをベースにメモリ64GBとSSD2TBの追加。

Zen3の8コアにRTX3060載せて総額21万円弱は合格点だろう。

内訳はPC本体15万円,メモリ3.5万円,SSD2.3万円といったところ。

GIGABYTEの一般モデルはRTX3070搭載等でこれより高額となるようだ。

ちなみに,高スペックモデルが存在する筐体の低スペックモデルを選定するのは熱設計の余裕を考えた選定である。熱的に頭打ちになる性能なら大差なしとの判断であるが正解か不正解かは両方を並べないと分からないだろう。ヒートパイプ等が共通パーツではない可能性もある。

 

 

 

 

開けて分かったが2.5インチSATAドライブも入る。今回はSSD1TBに2TB追加したのでもう十分かと。

電池パックの交換が可能なものも久しぶりな気がする。実際外すことがあるかどうかは分からない。

 

雑感として見た目ほど重くはないが厚みがあって嵩張る感がある。熱設計によるものと思われる。

それと,右シフトキーが小さい。うっかり「カーソル上」が入る。

Alder Lakeでやねうら王ベンチ(その3)

bleu48.hatenablog.com

 

前回に続きます。

前回の最後で12900Kがfloodgateであまり強くなかった点で疑問を残して終わりました。今回は確認作業としてPコアのみの状態でfloodgateに放り込みました。

 

f:id:the48:20220216141124p:plain

 

近隣に内輪が集まってますがその点は置いておいて,12900Kと12900KのPコアのみが4225と4251で僅差となりました。Pコアのみはもちろん16スレッドです。

8コア16スレッドでこの位置とすれば素晴らしいのですが,せっかくのi9と考えるとちょっと残念な結果です。

 

bleu48.hatenablog.com

 

そういえば,上記リンクのようにM1でも同じような結果でした。つまりPコア4,Eコア4のM1においても4スレッドと8スレッドで僅差の結果でした。このときはEコアが役立たずなので探索に要らないとざっくり切り捨てたのですが,Alder Lakeはそうもいきません。

なんせAlder LakeのEコアはそこそこ速いはずなのですから。

 

Eコアが要らないとなれば,若干クロックが下がるi7 12700Kで十分となります。Eコアに負荷がかからない状態で十分となればi7 12700でも熱的に余裕が出て近いパフォーマンスを叩きだす可能性すら出てきます。

 

さて,ちょっと想定外の事態ですが問題を整理しましょう。

1.そもそもLazy SMPで遅いコアが役に立たない(これは可能性が低いが学術的には面白い)

2.Stockfish実装(やねうら王実装)の不備で遅いコアの効果が相殺される(学術的価値はあまり無いが改善されれば多くの人が嬉しい)

3.今回の計測に誤りがある(まぁ,100戦以上してるが時期がズレたなどでレートがシフトしているなどの可能性はゼロではない)

 

いずれにしても電竜戦や選手権などの大会ではAlder Lakeが上位争いすることはないと思いますので関係ありません。

PonderとUSIプロトコルとフィッシャールールと時間切れと私

検索で飛んでくる人用に簡単に書いておくと,2017年将棋電王トーナメントで相手考慮時間において指し手予測を複数行うことで自分の手番で時間をあまり使わずに対応するエンジンを作り準優勝した。キーワードがPonder,本手法をMulti Ponderと命名している。

元ネタは単なる思い付きで全着手ノータイムのおもちゃを作りたかったからだ。

第5回 将棋電王トーナメント | ニコニコ動画

 

時間管理(チェスでtime control)はチェス由来のフィッシャールールが適用されることが多い。本家(チェス界)では知らないが以下はコンピュータ将棋界のルールで説明する。

持ち時間5分一手10秒加算というのがfloodgateのルールである。世界選手権は持ち時間15分一手5秒加算,電竜戦では持ち時間10分一手2秒加算と皆諸事情あって異なっている。floodgateも元は選手権由来であるらしい。

http://wdoor.c.u-tokyo.ac.jp/shogi/floodgate.html

持ち時間を過ぎたら負けであるから,floodgateルールだと初手で5分であると思われがちなのだが初手から5分10秒使える。これは囲碁将棋などの秒読みルールからの転用が理由だと言われている。フィッシャールールでは指す毎に時間加算とあるから間違っている気もするが現行のプログラム実装を優先する。

実はやねうら王も随分の間(少なくとも2017,2018年頃)この加算分を使っていなかった。常に余裕を残していたのだが今はこれを加算するようになっている。つまり現在ギリギリの設定である。

 

で,順が後になったが探索エンジンとの通信に用いられるUSIプロトコルである。各方面で問題点を指摘されているが,ここではPonderの件についてだけにしておく。

将棋所:USIプロトコルとは

USIプロトコルでは盤面の設定にpositionコマンド,探索実行にgoコマンドを用いる。

通常は問題ないが,Ponder時はgo ponderで探索実行開始する。Ponder手が当たればponderhitコマンドを送り探索を継続するし,外れればstopコマンドで停止させ再度goコマンドを送る。goコマンドの引数に持ち時間を与える。

ちなみにネット対戦で用いられるCSAプロトコルでは着手毎に使用時間が返ってくるためにそこから毎回持ち時間が逆算可能である。

 

USIプロトコルのどこに問題があるか?

ponderhitのタイミングである。go ponder時に持ち時間を入れる。相手が考慮して指し手を送る,受け取ったらそれでponderhitとしてエンジンに送る。ponderhit時には時間情報を送らない。

つまり,エンジン側は相手の考慮時間をどのくらい消費したかエンジン内でカウントする必要があるのだ。具体的に言うと,ponderhitが少しでも遅れればエンジン側からすれば相手の考慮時間が消費されたと考え,自分の考慮時間が消費されたことに気付かない。エンジン側からすれば悠々時間切れとなる。

ponderhitに引数はないので,プロトコル上補正する手段は無い。

 

go ponder中はponderhitコマンドのタイミングに対してシビアな状況であるにも関わらず探索中の情報もリアルタイムで出力されているため,それらの処理も必要となる。

まぁ,そういった僅かな差であるが数手蓄積されると時間切れになるらしい。やっと修正できたので時間切れの負けがなくなった模様。

実際ギリギリまで時間を使っていることを確認している。(test06側)

test06 vs. Kristallweizen_R9-3950X (2022-02-09 08:00)

 

以下,追記予定。

ーーー

某所で話題になっていたが,ponder中にstopやponderhitではなく突然gameoverが飛んでくる場合がある。(先手番の)max movesの場合と(相手番での)千日手の場合である。将棋所の方で一度stopを入れてもらえないかと以前打診したが仕様なので変更しないと回答頂いた。stopある方が無難なのだが仕様ならしようがない。

 

---

さらに追記。というか本体。

csa_usi_bridge_4fg.py · GitHub

floodgateで連戦するためのスクリプト

上記のややこしい話に加えて対戦相手がマッチしなかった場合にタイムアウトして再接続待機部分が大きな変更。

ただし,その際に用いたtimeout_decoratorのためにWindowsPythonで動かないことになった。まぁ,Windowsなら将棋所使いましょう。

Alder Lakeでやねうら王ベンチ(その2)

bleu48.hatenablog.com

 

前回の続きです。

12900Kがどの程度なのかfloodgateに丸二日放り込んで100戦弱やってみました。

f:id:the48:20220207151308p:plain

 

Ryzen9 3950Xを超えると思っていたのですが,若干下のレートで止まりました。

同じKristallweizen評価関数なので実力なんでしょうか。

探索部は12900Kの方が新しいんですがそれが裏目に出たのかもしれません。

まぁ,未確認なので僅差って扱いにしておいて下さい。

Ryzen9 5950X買う方が良いんじゃないかと思う人は是非買って計測手伝って下さい。

 

ところで,以下の記事でEコアのみのベンチマーク計測の方法が掲載されていました。

LimitCPUというアプリを使えばできるようです。

pc.watch.impress.co.jp

www.vector.co.jp

 

ざっくり計測してみました。

f:id:the48:20220207162613p:plain

f:id:the48:20220207162624p:plain

ついでに,Pコアのみのベンチマークも。

f:id:the48:20220207162644p:plain

f:id:the48:20220207162722p:plain

 

まぁ,前回書いたものが確認されたという感じでしょうか。

Eコアのシングルで900knps弱出ています。8コアで平均700knps超えています。

Skylake級と言って良いと思いますし,Zen1級と表現してもいいかもしれません。

全負荷ならEコア8個で6Mnps弱稼いでいる感じですね。

 

Pコアの方は1~8は変わらずですが,16スレッドでHT全負荷の具合が分かります。1スレッド1Mnps強あって,16スレッドで16Mnps強という感じですね。さすがにEコアより強いです。

Pコアが8スレッド時(各コア1スレッド)にスレッド辺り1.5Mnpsで,16スレッド時にスレッド辺り1Mnpsとなるが,この落差よりEコアの方が働いていると確認できました。

 

概ね納得なのですが,冒頭のレーティングだけちょっと気になります。

スレッド毎の性能にばらつきがあると強くならないんでしょうか?

ちょっと面白い課題として残しておきます。

Alder Lakeでやねうら王ベンチ

仕入れていたマザーボードがATX8ピンを2つ要求するのに気づかなかったので出遅れました。やはり自作とはいえ同世代のパーツだけで組むのがトラブルが少ないようです。

 

12900Kでやねうら王ベンチを走らせておきました。

バージョン7.0.0,NNUE tournament clang avx2のMizarさんの配布バイナリ,評価関数はKristallweizenです。

メモリはDDR5の4800MHz(デフォルト値),OSはもちろんWindows11です。

PコアEコアの構成がありますのでスレッド数をざっと振ってあります。

 

f:id:the48:20220203102638p:plain

 

最大24スレッドで23Mnps付近まで行きますので旧i9の10980XEやZEN+世代のスリッパ2990WXなどと並びます。伊達にi9じゃないのですね。(ちなみに熱量も)

ざっと見れば8スレッドまでは快調でそこからなだらかになる感じです。もちろん最初の8スレッドまではPコアを占有します。

 

スレッド当たりが気になるので以下のグラフも書いてみました。

 

f:id:the48:20220203102656p:plain

 

まず驚異的なのがシングル性能ですね。1.6Mnpsは新記録じゃないでしょうか?

impressの記事でもありましたが,本当に出ますね。この時点のクロックが12900Kのスペックシート通りの5.1GHzです。ここから8スレッドまでゆるやかに下がりますがこれはベースクロックが下がるので仕方ないですね。

最終24スレッドでも1Mnps弱あるのは驚異的ですね。Pコアの話題が目立ちますが,Eコアも相当速い感じです。Skylake級と言われてますがやねうら王ベンチだと超えてそうです。

 

面白いのは9~16はPコアのHTではなくEコアに負荷が行くところです。

表現を変えると,Pコアひとつで2スレッドよりPコアEコアふたつで2スレッドの方が明確に速いということです。多スレッドのアプリならEコア増やす方がダイ面積もエネルギー効率もはっきり高いと言えます。

ノート用のAlder Lake-UでPコア2,Eコア8の構成がありますが実はデスクトップで採用しても良いくらいリーズナブルな設計なのかもしれません。実機見てみたいものです。

ちなみにApple M1だとPコアとEコアでは性能が一桁ほど落ちますから相当な設計点の相違があります。(他のARMは知らないのでごめんなさい)

 

コア指定してスレッド起動する方法などありましたら教えて下さい。

---

そういえば失敗企画ですが一時期インテルがEコア(所謂Atom)を多コア満載のサーバ用Xeonを作った気持ちが分かる気がしてきました。方針間違えては無いと思うんだけど,イメージ的に売れなかったんでしょうね。

ーーー

追記:

その2へ続きます

bleu48.hatenablog.com

例外

例外処理はプログラミングで必ず出てくるものだが,これも程度問題で言語レベルで実装されている機能もあれば他愛もないものなら簡単な分岐で済ませてしまうこともある。

実生活では気にも留めず流したりするようなことも計算機ではそうもいかないので,色々明確な指示を出さなくてはならない。組織運営もそうなるのであるがこれが多くなると酷いというのは学校のやたら長い校則やら長寿法人の意味不明の社訓とかそういうのになる。

 

いあ,ちょっとしたものを見つけたのでね。

2016年floodgate棋譜で以下のものがあった。

wdoor+floodgate-600-10+TAKUYA_HIRAOKA+Sunfish4_alpha4+20160214223004.csa

 

初手入玉宣言で反則負けである。

これを読むだけでcshogiのパーサが落ちる。何十万とファイルがあってこれひとつだけ。バグ報告するかどうか迷ってネタにしてるというオチw

 

Windows11導入(個人メモ)

メモ書きだけど,誰かの役に立つかもしれないし,忘れたころ自分が探すかもしれないので公開しておく。

 

私は機械学習Windows派である。Linux環境の人が多いようだけど,基本的にリソース管理が楽だから使っているように聞いているので成果を出すにはどちらでもいい。共用マシンはWindowsじゃない方がいいだろうとは思う。

私個人的には学生さんも閉ざされた環境より,低パフォーマンスでも権限持って一台使う方が学びが多いと思っている。

 

で,昨今Windows用のNVIDIAGPUドライバがアップデートされたときに古いCUDAが入っているマシンで明確なパフォーマンス低下があった。一応動いてはいる。山岡さんも経験済みのようだ。

Windows11+WSL2+Dockerでdlshogiを動かす - TadaoYamaokaの日記

Windows11+WSL2+Dockerでdlshogiを動かす 続き - TadaoYamaokaの日記

 

一般向けドライバがWSL対応したとの話とCUDA旧バージョンで遅くなったとの話がリンクしているようなので,CUDAの方を上げるのもいいが,この際WSL導入もいいかもしれないと一台だけWindows11のCUDA環境を構築しようとしている。

 

(バックアップも取らず進めた)Windows11へのアップデートはあっけなく終わり,WSLからnvidia-smiのコマンドもすぐにはいったが,ここでCUDAバージョン11.6との応答が出る。他の方も報告されているがまだCUDA入れてないぞとw

 

ここからdocker使うかどうかまだ悩んでいる。(加筆予定)

公式もdocker推奨なのよね。

CUDA on WSL :: CUDA Toolkit Documentation

 

---

1月26日追記:

結論から言うとdocker無しで動くようになった。

但し,理由は分からないがLTSのPyTorchにしたら動作した。1.10はダメだった。

くどいが理由は分からない。