Ryzenのクロック制御について

デスクトップのRyzenを仕入れたときに感じたことがある。

８コア１６スレッドとか何に使うんだろうってやつだ。

で，既存のプログラムを幾つか走らせた際に感じた違和感がある。

シングルスレッドプログラムを走らせた場合にCPU負荷が4%にしかならないってことだ。そして，インテルのCPUと違ってこの時点でターボブースト（AMDは別の呼称だった気もする）が入らない。つまり，定格以下の省電力モードである。

もう一つ走らせるとクロックがほどほどに上がる。

　

で，困るのがこういうことだ。

ディープラーニング用のPCスペックについて - 48's diary

シングルスレッド性能が速いのが欲しいときがある - 48's diary

シングルスレッド性能が欲しい時に困る。

　

具体的な例としてはAobaZeroベンチのRX 580である。

AobaZeroベンチ - 48's diary

こいつは値崩れてたゲーミングノートのGPUなんだが，CPUがデスクトップ仕様のRyzenである。

www.asus.com

　

で，AobaZeroベンチで6秒クラスって言ってたんだけど，別に余計なスレッドを走らせてやるとCPUクロックがまともになって，4秒台になるんですよね。

これが本来の性能でした。

　

また別の話として，二世代目のRyzenだと2コア単位でクロックが変動してる。

で，高熱になるとそれぞれ適当に独立してクロックが下げられる。

例えば4コアのRyzenノートPCだと2コアが3GHzで残りの2コアが2GHzってことがある。

一番速くしてほしいスレッドが低クロックのコアに当てられる可能性とかあるんじゃないかなぁと想像してる。

　

こういうの次のRyzenとかで修正されてんのかねぇ。

なんか対策あったら教えてほしい。

 

コンピュータ将棋入門について

コンピュータ将棋界隈には色んな人がいます。

元奨励会員などの将棋の強い人，ゲーム情報学含め情報系の学生・研究者，対戦大好きなゲーマーやプログラマーなどジャンル分けはクロスするので避けますが，結構な色物揃いです。

理由は実のところ要求スキルが幅広いことが挙げられます。

将棋のルールをコーディングするだけにも二つのジャンルの知識が必要になります。

近頃はこれに加えて最先端のAI技術ですね。

 　

じゃ，今から入門って大変なのかと言うとルート次第でしょうね。

簡単にできるものとして，ゼロから全部作るのではなく既存の物を改造する方法があります。

ライセンス問題も生じないようにオープンソースの物をベースにするのがよいでしょう。

やねうら王の評価関数や定跡のみを差し替えるというのが今定番の入門でしょう。

　

別のルートを案内します。

棋譜解析です。実際欲しい機能がこちらと言う方が相当多いはずです。

自分なりの棋譜解析なんかは結構面白いと思います。

以前より紹介してるpython-shogiなどを用いると棋譜ファイルの読み込みなどは簡素に書けるのでお勧めです。

　

昨年学生向けに提示した練習課題をリストにしておきます。

練習用の棋譜ファイルは適当に対戦させて作るか，floodgateからでもダウンロードしてください。

１．棋譜ファイルから終局までの手数を得る

２．棋譜ファイルから初手を得る

３．棋譜ファイルから玉の移動した手だけを得る

４．棋譜ファイルから玉の移動したマスに着色する

５．複数棋譜ファイルから玉位置のヒートマップを作成する

６．複数棋譜ファイルから入玉した棋譜だけ得て，入玉率を算出する

　

同様に

１．棋譜ファイルから桂打ちのみを得る

２．桂打ちの際の利きを確認する

３．多くの棋譜ファイルから桂打ちを分類する（合い駒，両取り，繋ぎ桂，王手など）

　

駒の損得を計算する

成り駒を出現を検出する（さらに馬や竜など駒を区分する）

多くの棋譜ファイルから同一手順や同一局面を探すツールなどは簡単に作れるはずです。

頓死や戦型など様々に分析をすることも可能だと思います。

高度な解析をするには他のプログラムを呼び出して使うようなことがあると思います。

たとえば「詰めろ」を検出するには手番をパスして，詰将棋エンジンに詰みがあるかどうかを判定してもらえば簡単に答えが得られます。

振り飛車の左桂に着目して大量の棋譜から統計的なデータを得るような試みがあってもよいように思います。

　

ってことで，対戦や評価値だけじゃないのよ。

　

つーか，そもそもそういう動機でコンピュータ将棋やってるので，独自の出力データを上手に可視化すると結構面白いと思ってる。

温故知新（番外編）

温故知新シリーズが割と続いているが，AbemaTVから先日このようなものが届いた。

　

f:id:the48:20190622105527p:plain

温故知新

　

当選知らせの段階では伊藤沙恵女流二段としか知らされていなかったが，揮毫される文字をみると当選者決まってから書かれた？とか勘ぐってしまう。

偶然ですかね？

　

こういうの証券ニュースサイトのボールペン以来かも。

---

追記：

女流二段ってことはAbemaTVトーナメント収録時だと思うので偶然です。（今は女流三段ですね）

温故知新（Bonanza）

GeoCitiesの消滅と共に公式サイトが無くなったBonanzaである。

ちょっと（どころじゃないか）出遅れた感があるが，温めてみよう。

きっかけはこのツイート

 　

実はBonanzaがGeoCitiesで配布されていた頃，一部のライセンス規定が引っ掛かりGPLと共存できないのではないかとかオープンソース規定に入るか入らないかなどの話題があった。過ぎたことなので厳密な部分はここでは触れない。

　

AobaZero内に確かにbonaというフォルダがある。

https://github.com/kobanium/aobazero/tree/release/src/usi_engine/bona

　

オリジナルと比較すればよかったんだが，保存してなかったのでクジラちゃん作者のえびふらい氏の改造エンジンと比較した。

Bonanza6.0 USI - クジラちゃんの駒箱

https://bitbucket.org/ebifrier/bonanza_usi/src/master/

　

簡単にはほぼ完ぺきに同じファイルがあると言っていい。

差分はUSIプロトコルに対応した追加分とAobaZeroに対応した追加分と言ったところだと思う。後者はyssで始まる4つのファイルも含む。 （wcsc28のYSS Zeroの派生だろう。）

ということで，ちょっとした改造でUSIエンジン化できた。ビルド環境はもちろんMSYS2である。

コンパイラの性能差かえびふらい氏のものより若干高速化された気もする程度のほぼ同等の強さのエンジンである。つまり6.0相当と考えていいのだろう。

　

すぐにどうこうということはないが，実験ツールにひとつ追加と言ったところか。

C++ではなくC言語と言うのがひとつ特徴かな。

元々かどうか知らないがswitch文のfall through警告が沢山でるので注意。

---

追記：

そういえば保木先生はもっといいソースがあるのでそういうのベースに開発した方がいいように言われてました。

AobaZeroベンチ

 　

将棋界のLeela ZeroであるAobaZeroのベンチマークを計測してみた。

可能な限り高速なマシンでたくさんの棋譜を送りましょう。

　

github.com

　

適当に集計していたのをまとめておく。

一手2秒クラス：GTX1080Ti Titan X

一手3秒クラス：Quardo P6000

一手5秒クラス：GTX1060 GTX1050Ti

一手6秒クラス：RX 580

一手17秒クラス：Ryzen5 2500U （自己ビルド）CPU版では130秒クラス

一手25秒クラス：Quadro K2000

一手30秒クラス：インテル内臓GPU（第7世代以降），i7 5557U (Iris 6100)

一手100秒超クラス：CPUのみ（クロック次第で100~200秒）

　

うんざりするのでCPUで回すのはやめておいた方がいい。

それとノートパソコンはGPU搭載でも疲弊するのであまりお勧めできない。

RTX 2080TiとかTesla V100とか持ってる人は計測して教えて下さい。 

---

2020年2月追記：

Ryzen Embedded V1202B (Radeon Vega 3)

一手34～35秒

RTX 2080Ti

一手2秒前後

develop版で２～４倍程度高速化するのでこれはそろそろ意味ないかも。

計測メモ

DL勢の計測をしていた。

　

AobaZero 9

bin\aobaz -q -p 2500 -n -m 10 -w weight_save\w000000000559.txt

（1080Tiで一手7秒強ほぼ一定）

dlshogi wcsc29

5分5秒加算（フィッシャールール）

200戦で10勝190敗

　

上記ルールは思考時間を適当に合わせるために設定。

同じ土俵にはまだ遠い感じ。

そもそもdlshogiが1080Tiで6000nps程度は出るのでノード数に差がある。

　

ところで，以前予告した通りdlshogiとある程度の実験をしたいのだが，選手権のような対戦には程遠い計測しか出来ていない。Tesla V100を仕入れないとダメなんだろうか。

きっちり実装を確認してからとしたいところだが昨今あまり時間的余裕がない。

　

寝かせても公開せず捨てるだけなので興味ある人に意味があるうちに晒しておく。 

定跡の手数の話

yaneuraou.yaneu.com

　

この件，そういえば二年前電王トーナメントで立ち話をした記憶がある。これもリアクションが薄くて，あまり気にしたことのある人がいないって感じだった。

　

我々が二年前に通過した場所だ！！！（ってほど力説する気もないが）

自分のところをの実装を確認したら，読み込み時にgameply読み飛ばしていた。

同一局面はどうなるかと言うと読み込み時にmergeされるわけだ。実に単純。

尚，一意性は保証されているらしい。

sfen文字列は本来は一意に定まる件 | やねうら王 公式サイト

　

適当な実装なので一手損角換わり等の先後入れ換え型はマッチしていない。

対応してもよかったんだが手抜き感が持ち味だろう。今から対応してもよさそう。

盤面180度回すのも，さほど難しくもないな。

　

まぁ，定跡生成のルーチンとして利用していたのでファイル形式まで変更するのが手間だったのが一番の理由。読み捨てるのはもっとも楽な対応だったんだろうなぁと当時を振り返る。実装は辞書形式，PythonでもGo言語でも習作レベルで特に問題なかった。

特にGo言語ではgoroutineで呼ぶと読み込み時間中にクライアントノードの初期化等も並行して行っていたので実のところオリジナルより初期化が早かった。

　

ということで，個人的なコメントとしては生成時には気にしなくていいんじゃないかなぁって感じです。OnTheFlyでなければ読み込み時に混ぜるのは何の苦もないので。

　

あと，個人的に定跡のテストは部分変更で多パターンを繰り返すので部分変更可能な方がいい。ってことでうちは複数ファイルに分割してる。今のところ３ファイルで並行探索で優先採用がデフォルトかな。もちろん最優先が実験定跡。

この辺は比較的簡単に色々遊べるので試してみるのが一番と思っている。