簡易的に 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 から順にスレッドの affinity を設定すると、1つのコアに 2スレッドずつ張り付きます。どういうことかと言いますと、4スレッド起動したとき、コア 0 とコア 1 に 2スレッドずつ張り付いて、他の 6コアはヒマになるということです。これはあまり効率が良くなさそうですよね?
今回の測定では、コアを使い切ることを優先してスレッドを割り当てました。当然ながら 16スレッドの性能は変わらないのですが、途中の傾向が少し変わります。
消費電力は 4コアの時点でピークにかなり近くなります。8コアじゃないのは何ででしょうね?2コアがペアで電源制御されているんでしょうか……?
電力効率は 8スレッドが最大で、16スレッドに向かってやや下がります。SMT の特徴が出ている感じがします。
メモ: 技術系の話は Facebook から転記しておくことにした。多少修正。
以前の日記(2019年 3月 17日の日記参照)で、Windows Update のあとにウインドウのタイトルがズレてしまう話を書きました。
その際に同時に発生する画面がぼやけてしまう現象についてもスクリーンショットを取ったので載せておきます。
このようにフォントがボヤけてしまいます。タスクマネージャの場合はあまり目立ちませんが、アプリケーションによってはさらに顕著です。
前回は「再起動で直る」と書きましたが、サインインしなおすだけでも直るようです。
ざっくりいうと、Windows Update がテキストサイズの拡大縮小設定を元に戻した後に、サインインしなおさないからじゃないか?と思っています。
Windows 10 にはアプリケーションのテキストサイズを調整する機能があります。[Windows の設定] -> [システム] -> [ディスプレイ] から設定できます。
設定変更すると一部のアプリは、サインアウトするまで、拡大縮小の設定に応答しません、という警告文が表示されます。
購入当初は 125% の設定になっていました。初期値はディスプレイの物理的なサイズと解像度によって決まっているそうです。あと、私は拡大縮小の設定を「100%」に変更して使用しています。
以上から導いた私の予想ですが、
こんな状態になっているのではないかと思っています。
先日(2019年 3月 24日の日記参照)作った memaccess(GitHub へのリンク)細かい部分が色々バグっていたので直しました。
アドレスの指定は文句なしで 64bit 符号なし整数にしましたが、書き込む値については 64bit の符号つき整数(今はこっち)と 64bit の符号なし整数の、どっちが良いんでしょうね。贅沢を言えば、どちらも使いたいですけど。
昨今のキャッシュを持った CPU では、DMA を行う際に CPU のキャッシュのフラッシュ(ダーティデータをメインメモリに書きだす、パージともいう)やインバリデート(キャッシュから消しさる、クリーンともいう)が必須です。
しかしアーキテクチャや CPU の実装によってキャッシュの操作方法は異なるため、Linux では DMA API というレイヤでアーキテクチャの差分を隠蔽しています。
Linux で DMA を行うドライバを書くときの一番単純な作法(=単一の領域に DMA を行う、スキャッターギャザーなどはしない)は、
ざっくりいってこのような感じです。先ほど述べた通り、Linux の DMA API にキャッシュのフラッシュやインバリデート関数はありません。ハード依存の操作をなるべく減らし、多数のアーキテクチャに対応しやすくなっているんですね。
そうはいっても、実際にどこでキャッシュフラッシュしているか、気になると思います。昔、Linux 4.4 を調べた情報を引っ張り出してきました。アーキテクチャは AArch64 つまり 64bit の ARM コアです。
AArch64 の場合、キャッシュ操作をしているのは dma_sync_single_for_cpu() と dma_sync_single_for_device() です。前者がインバリデート、後者がフラッシュ+インバリデートを行っています。
前者の dma_sync_single_for_cpu() を追いかけてみると、
こんな感じですね。しつこいですが AArch64 の実装を見ただけですので、将来的に変わるかもしれないし、他のアーキテクチャでは仕組みが違います。
昔の Linux ではキャッシュ操作関数をドライバから使うことができました。その記憶からなのか、たまにフラッシュやインバリデートのようなアーキテクチャ依存の操作を直接呼びたがる人がいます。
今の Linux ではキャッシュ操作関数は当然ありますが、ドライバからは呼べない、つまり呼ぶことを推奨していません。もちろんオープンソースなので改造すれば何でもできますけど、メンテナンス性や再利用性、移植性を下げるだけで、損しかないでしょう。
目次: RISC-V - まとめリンク
Linux が動くくらいの RISC-V の SoC 搭載ボードを探していたのですが、どうやらまだ市販されてなさそうでした……。
代わり(?)に SiFive の高性能 RISC-V SoC である HiFive Unleashed(リンク)のマニュアルを眺めていました。
HiFive Unleashed は高性能と紹介されていることが多いですが、現状 RISC-V は Arduino くらいの小規模 SoC がほとんどで、それらと比較して高性能、と言っているのだと思われます。
特に珍しい機能もないですし、最近のテレビやタブレット向けの巨大な ARM 系 SoC と比べると、どうしてもショボく見えてしまうのは仕方ないでしょう。
ああ、でも Errata の章があるのは珍しいかもしれません。
などの豪快なバグがある様子が伺えます。特に ROCK-2 の Workaround は全然 Workaround になっておらずのが面白いです。アクセス違反をするな、と言ってアクセス違反がなくなるなら OS の苦労はないでしょ。かなり悲惨なバグです。
ボードには修正した SoC を載せるのか、バグった SoC を強引に搭載するのか、どちらなんでしょうね……。
メモ: 技術系の話は Facebook から転記しておくことにした。
先日(2019年 3月 27日の日記参照)クロスビルド向け LLVM のビルド方法がわかったので、今度はクロスビルド向け GCC のツールチェーン(超基本的な binutils + GCC + glibc の組み合わせ)を作ろうとしていますが、さっぱりうまくいかないです。
そもそもどのバージョンの組み合わせならビルドが通るのか全くわかりません……。対象となるクロス環境(ARM 向けなのか、RISC-V 向けなのか)と、ホスト側のコンパイラバージョンが影響するようで、昔ビルドが通っていた組み合わせを引っ張り出してきても、今の環境だとビルドが通らないなんてことがおきます。
ビルドできる組み合わせは頑張れば見つけられるとは思いますが、本来やりたいことはクロスビルド用のコンパイラのソースコードリポジトリをダウンロードし、自分でソースコードに何か変更を入れ、変更した内容も含めてビルドすることです(ダウンロードは最悪手動でも良いですけど)。
世の中にはクロスビルド用のツールチェーンを作成できるツールはいくつかありますが、いずれも tarball からのビルドを想定していて、改変を入れて再ビルドする方法が良くわかりません。
ツールが想定しているリリース用のビルドは、
開発用は、リリース用に加え、
が必要ですが、意外とできないです……。
いくつかツールを調べてみました。
ツールチェーン単体だと crosstool-NG ですし、将来的に追加するものを考えると buildroot が良さそうですけど。変更を反映して差分ビルドする方法ないのかな……??
引き続き、超基本的な binutils + GCC + glibc の組み合わせのクロスビルド環境を作っています。やや苦戦したものの、ARM, AArch64, RISC-V 64 でビルドが通りました。良かった良かった。
残念ながら RISC-V 32 は glibc が対応しておらず、libc なしのベアメタル向けコンパイラしか作れませんでした。glibc does not yet support 32-bit systems と怒られます。glibc の代わりに newlib などを使えば、libc ありの Linux 向けコンパイラが作れるかもしれませんが、試していないのでわかりません。
昔作ったクロスコンパイラをビルドする Makefile(GitHub へのリンク)を改造して、作りました。
前回(その 1)検討した通り、本格的に運用するなら独自のビルドツールより crosstool-NG か buildroot に切り替えた方が良いと思います。
詳細は GitHub を見た方が良いですが、configure に指定しているオプションだけ、ざっと列挙しておきます。
CROSS_ARCH = riscv64-unknown-linux-gnu
TOP_DIR = `pwd`
CROSS_ROOT = $TOP_DIR/buildroot
PREFIX ?= $(CROSS_ROOT)
SYSROOT ?= $(CROSS_ROOT)/$(CROSS_ARCH)/sysroot
まず binutils は、
./configure \
--target=$(CROSS_ARCH) \
--prefix=$(CROSS_ROOT) \
--disable-nls \
--disable-static \
--disable-werror \
--with-lib-path=$(CROSS_ROOT)/lib \
--with-sysroot=$(CROSS_ROOT)
次に gcc は、
./configure \
--target=$(CROSS_ARCH) \
--prefix=$(PREFIX) \
--enable-languages=c \
--disable-libatomic \
--disable-libitm \
--disable-libgomp \
--disable-libmudflap \
--disable-libquadmath \
--disable-libsanitizer \
--disable-libssp \
--disable-libstdcxx-pch \
--enable-long-long \
--enable-lto \
--disable-multiarch \
--disable-multilib \
--disable-nls \
--disable-plugin \
--disable-shared \
--disable-threads \
--disable-__cxa_atexit \
--without-headers \
--with-local-prefix=$(SYSROOT) \
--with-sysroot=$(SYSROOT) \
--with-newlib
難関の glibc はこんな感じ、
./configure \
--host=$(CROSS_ARCH) \
--prefix=$(SYSROOT)/usr \
--disable-profile \
--disable-multilib \
--enable-add-ons \
--enable-kernel=3.0.0 \
--disable-multi-arch \
--enable-obsolete-rpc \
--with-binutils=$(PREFIX)/bin \
--with-headers=$(SYSROOT)/usr/include \
--with-sysroot=$(SYSROOT)
最後に glibc を動的リンク可能な gcc は、
./configure \
--target=$(CROSS_ARCH) \
--prefix=$(PREFIX) \
--enable-languages=c,c++,fortran \
--enable-libatomic \
--disable-libitm \
--enable-libgomp \
--enable-libmudflap \
--enable-libquadmath \
--disable-libsanitizer \
--enable-libssp \
--enable-libstdcxx-pch \
--enable-long-long \
--enable-lto \
--disable-multiarch \
--disable-multilib \
--enable-nls \
--enable-plugin \
--enable-shared \
--enable-threads=posix \
--enable-__cxa_atexit \
--with-local-prefix=$(SYSROOT)/usr \
--with-build-sysroot=$(SYSROOT) \
--with-sysroot=$(SYSROOT) \
--with-native-system-header-dir=/usr/include
この設定が正しいかどうか確証は持てませんが、printf を呼び出す C ソースコードをエラーなくビルド可能なコンパイラが作成できるので、良しとします。
色々引っかかったのですが、覚えている限りのエラーと自分が取った対策を列挙しておきます。
エラーメッセージだけ読むとさっぱりですが、config.log に記録されたテストプログラムとテスト結果によれば、pthread.h が見当たらないと言っているようです。
もちろん GCC の前に glibc のクロスビルドに成功しているので、pthread.h は存在しているものの、
これらの原因によって、pthread.h が見えなくなっていたようです。
ツールチェーン構築って大変です。実際に体験すると、crosstool-NG や buildroot のありがたさが身に沁みます。
管理者: Katsuhiro Suzuki(katsuhiro( a t )katsuster.net)
This is Simple Diary 1.0
Copyright(C) Katsuhiro Suzuki 2006-2021.
Powered by PHP 5.2.17.
using GD bundled (2.0.34 compatible)(png support.)