コグノスケ

レジスタダンプ、書き換えツールmemaccess - ちょっと修正

先日（2019年3月24日の日記参照）作ったmemaccess（GitHubへのリンク）細かい部分が色々バグっていたので直しました。

• 32bit環境でビルドできない
• ビルド時にlibtoolを要求する（本来は要らない）
• 0x80000000_00000000以上のアドレスを指定すると0x7fffffff_ffffffffになってしまう
• 32bitを超える値を書き込めない

アドレスの指定は文句なしで64bit符号なし整数にしましたが、書き込む値については64bitの符号つき整数（今はこっち）と64bitの符号なし整数の、どっちが良いんでしょうね。贅沢を言えば、どちらも使いたいですけど。

ぼやけるWindows

以前の日記（2019年3月17日の日記参照）で、Windows Updateのあとにウインドウのタイトルがズレてしまう話を書きました。

その際に同時に発生する画面がぼやけてしまう現象についてもスクリーンショットを取ったので載せておきます。

ボヤけている状態

このようにフォントがボヤけてしまいます。タスクマネージャの場合はあまり目立ちませんが、アプリケーションによってはさらに顕著です。

サインアウト、サインインしなおした状態

前回は「再起動で直る」と書きましたが、サインインしなおすだけでも直るようです。

ボヤける理由の予想

ざっくりいうと、Windows Updateがテキストサイズの拡大縮小設定を元に戻した後に、サインインしなおさないからじゃないか？と思っています。

Windows 10にはアプリケーションのテキストサイズを調整する機能があります。[Windowsの設定] -> [システム] -> [ディスプレイ] から設定できます。

拡大縮小設定を変更したときの警告文

設定変更すると一部のアプリは、サインアウトするまで、拡大縮小の設定に応答しません、という警告文が表示されます。

購入当初は125％ の設定になっていました。初期値はディスプレイの物理的なサイズと解像度によって決まっているそうです。あと、私は拡大縮小の設定を「100％」に変更して使用しています。

以上から導いた私の予想ですが、

• Windows Updateによって、テキストサイズの設定が初期値（125％）に戻る
• Windows UpdateがPCを再起動する
• アプリケーションがテキストサイズ125％ で表示する
• Windows Updateがユーザーが使っていたテキストサイズ設定（私の場合100％）に設定しなおす
• サインアウトは行わないため、アプリケーションがついてこられずボヤけてしまう

こんな状態になっているのではないかと思っています。

簡易CPU消費電力測定

簡易的にCPUの消費電力を測ってみました。測定ポイントはATX電源とACコンセントの間です。要はワットチェッカーでPC全体の消費電力を測っています。

アイドル状態から1スレッド、2スレッド、と負荷を増やし、
(負荷時の消費電力) - (アイドル時の消費電力) ＝CPUの消費電力
と見なしています。負荷には仮想通貨のマイニングソフトのベンチマークモードを使っています。それなりに複雑な計算と、スレッド数の制御が容易いので便利です。

Ryzen 7 2700のTDPは65Wなのに、消費電力が70W以上に計算されるところからわかるように、消費電力は若干多めに出ています。おそらくCPUの負荷に連動して冷却ファンが回ること、ATX電源の変換効率が負荷によって変わること、などが原因だと思われます。

スレッド数と消費電力

Ryzen 7 2700は8コア16スレッドですが、5スレッドを超えた辺りから、フルパワーの消費電力とあまり差がなくなります。

スレッド数と電力効率

またW辺りの計算効率（kH/s・W）を計算すると、16並列が一番効率が良いです。逆に5〜6スレッド程度だと効率が悪いです。中途半端な並列度で計算するくらいなら、16スレッドフルに使いきれということですね。

コア優先で割り当てたらどうなるか？

上記の実験方法を見て「スレッドをどのCPUに張り付けるかを制御しなくても良いのか？」疑問に感じた方、さすがです。手抜きしていたことがバレましたね。

マイニングソフトのコードを見たら、ちょいと改造すれば簡単にスレッドのaffinityを設定できそうだったので、改造してもう一度測りました。

まずRyzen 7 2700はSMT構成になっていまして、1コアが2スレッド実行可能（OSからは1コア ＝2 CPUとして扱う）です。私の環境Debian Testingだと、

• CPU 0: コア0スレッド0
• CPU 1: コア0スレッド1
• CPU 2: コア1スレッド0
• CPU 3: コア1スレッド1
• ...

以上のように割り当たるようです。ここで素直にCPU 0から順にスレッドのaffinityを設定すると、1つのコアに2スレッドずつ張り付きます。どういうことかと言いますと、4スレッド起動したとき、コア0とコア1に2スレッドずつ張り付いて、他の6コアはヒマになるということです。これはあまり効率が良くなさそうですよね？

今回の測定では、コアを使い切ることを優先してスレッドを割り当てました。当然ながら16スレッドの性能は変わらないのですが、途中の傾向が少し変わります。

スレッド数と消費電力、コア優先割り当て

消費電力は4コアの時点でピークにかなり近くなります。8コアじゃないのは何ででしょうね？2コアがペアで電源制御されているんでしょうか……？

スレッド数と電力効率、コア優先割り当て

電力効率は8スレッドが最大で、16スレッドに向かってやや下がります。SMTの特徴が出ている感じがします。

メモ: 技術系の話はFacebookから転記しておくことにした。多少修正。