link もっと前
   2019年 4月 5日 -
      2019年 3月 27日  
link もっと後

link 未来から過去へ表示(*)
link 過去から未来へ表示

日々

link permalink

簡易 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 から転記しておくことにした。多少修正。

[編集者: すずき]
[更新: 2019年 4月 2日 00:33]
link 編集する

コメント一覧

  • hdk 
    去年Ryzen 7 1700で測りましたがやはりTDPより少し高めでした: http://www.e-hdk.com/diary/d201808b.html#15-1 
    (2019年04月02日 22:48:26)
  • すずき 
    どの CPU というかシステムでも同じ傾向ですね。CPU の消費電力だけ測れているわけではないですし、そんなもんかなーと思いました。 
    (2019年04月05日 11:03:13)
open/close この記事にコメントする



link permalink

RockPro64 のシリアル文字化け - 真因発見か?

RockPro64 シリアル文字化けの話のまとめ、第二章。

RockPro64 のシリアル文字化け問題に進展がありました。結論から先に言えば、現在の linux-next の I/O ドメイン audio_gpio3d4a_ms の電圧設定が間違っていそうです。直したらシリアルの波形が綺麗になりました。

RK3399 は I/O ドメイン(正式な名前かどうか知らない)といって、いくつかの出力ピンがグループになっています。グループごとに電源ピンがあり、電源ピンに何 V を供給しているか設定する必要があるようです。audio_gpio3d4a_ms ドメインの電源は APIO5_VDD 端子です。

要は APIO5_VDD 端子に 1.8V を供給するなら、audio_gpio3d4a_ms ドメインの設定も 1.8V にする必要があり、APIOD5_VDD 端子に 3.0V を供給するなら、audio_gpio3d4a_ms ドメインの設定も 3.0V にする必要があります。

RockPro64 の回路図を見ると、P.4 の Power Domain Map というページに audio_gpio3d4a_ms には電源 IC(RK808)の VLDO7 が繋がっていて、1.8V だと書いてあります。linux-next はこの記述を見て設定していると思われます。

しかし P.16 の回路図を見ると、APIO5_VDD 端子には VCC_3V0(その先は VLDO8)という 3.0V 出力ピンが繋がっています。つまり RockPro64 の回路図は自己矛盾しています。


APIO5_VDD の配線図


VCC_3V0 の配線図

配線ミスってるとか、そんなのありかよ……と思いつつ P.16 の回路図を信じることにして、audio_gpio3d4a_ms を 3.0V 設定にするパッチを LKML に送りました。

偉そうに書いていますが、私は P.16 の回路図には全く気づいておらず、LKML のナイスガイ達に助けられました。ありがたいことです。

関係ないドメインなのに、なぜ影響するのか?

UART2 信号が出ている GPIO4_C3 ピンは gpio1830_gpio4cd ドメインに属しており、audio_gpio3d4a_ms ドメインでは「ない」です。にも関わらず、なぜか audio_gpio3d4a_ms ドメインの設定ミスで UART2 の波形がおかしくなります。

Power Domain Map と回路図の意図を整理すると、Power Domain Map の設計は、下記の通りです。

  • audio_gpio3d4a_ms - APIO5_VDD - VCCA1V8_CODEC - VLDO7
  • gpio1830_gpio4cd - APIO4_VDD - VCC1V5 - VLDO6, VCC3V0_IO - VLDO8

一方の回路図はというと、全然接続が違いますし、端子がなかったりします。

  • VCCA1V8_CODEC - VLDO7
  • VCC_1V5 - VLDO6
  • VCC3V0_IO 存在しない
  • audio_gpio3d4a_ms - APIO5_VDD - VCC3V0 - VLDO8
  • gpio1830_gpio4cd - APIO4_VDD - VCC3V0 - VLDO8


VLDO 系の配線図

推測ですが、意図せずに 2つのドメインで電源ライン VLDO8 を共有したために、audio_gpio3d4a_ms ドメインの設定ミスが、gpio1830_gpio4cd 側のドライブ能力に影響していると思われます。

VLDO8 に想定してない負荷が掛かっているような気がしますが、大丈夫なんですかね……??まあ、コスパ重視だし、趣味のおもちゃですから、燃えたり爆発したりしなければ問題ないのかな。

(補足)audio_gpio3d4a_ms ドメインの設定は、GRF_IO_VSEL レジスタ(アドレス 0xff77e640 )のビット 1 です。

[編集者: すずき]
[更新: 2019年 4月 1日 03:33]
link 編集する

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link permalink

GCC は必須

世界から gcc がなくなるとどうなるのか?と思ったので、試してみました。その世界では、少なくともターゲットとなる実機上でセルフコンパイルが可能になるまで、別の環境(例えば PC など)で、

  • clang
  • クロスコンパイル

を用いて世界を構築する必要があります。何もかも試すのは不可能なので、必要最小限の要素として、

  • ブートローダー(U-Boot)
  • カーネル(Linux)
  • libc(glibc, newlib)

を試すことにします。

最近は clang と gcc は互換性も高いし、楽勝でしょ〜などと生半可な知識で楽観視していましたが、実際やると何かもう全然ダメです。そもそも x86 向けのビルドが成功しません。クロスコンパイルなんか以ての外です。

RISC-V の人たちが GCC に真っ先に対応して、LLVM を放置している理由はこれかなあ?特に GNU, Linux 系システムをビルドしようと思ったら、LLVM だけでは話にならないのでは……??

U-Boot

まずは U-Boot です。

U-Boot を clang でビルド
$ make CC=clang defconfig
$ make CC=clang

うまくいきました。さすが!ARM とか AArch64 向けなら、U-Boot は良い選択肢のはずです。RISC-V は違うブートローダを使うので意味ありませんけど。

Linux

次は Linux です。

Linux を clang でビルド
$ make CC=clang defconfig
$ make CC=clang
HOSTCC scripts/asn1_compiler
HOSTCC scripts/extract-cert
Compiler lacks asm-goto support.
make: *** [arch/x86/Makefile:298: checkbin] Error 1

序盤でコケます。どうしたら良いんでしょう、これ。回避方法が見当たりません。

libc (glibc)

glibc を clang でビルド
$ mkdir build
$ cd build
$ ../configure --prefix="/usr" CC=clang
...
configure: error:
*** These critical programs are missing or too old: compiler
*** Check the INSTALL file for required versions.

まず configure が通りません。門前払いです。どうも clang を使ったとき、configure は GCC 3.x 系だと思うようで、そんな古いコンパイラはダメよ?と怒られてしまいます。どうしろと。

libc (newlib)

GNU 系列の glibc は clang に対応するとは思えませんし、newlib なら何とかしてくれるはず。

newlib を clang でビルド
$ mkdir build
$ cd build
$ ../newlib/configure --disable-multilib CC=clang CXX=clang++
...
In file included from ../../../newlib/libc/ssp/gets_chk.c:39:
In file included from /home/katsuhiro/share/projects/oss/newlib-cygwin/newlib/libc/include/limits.h:132:
In file included from /usr/lib/llvm-7/lib/clang/7.0.1/include/limits.h:37:
/usr/include/limits.h:145:5: error: function-like macro '__GLIBC_USE' is not defined
#if __GLIBC_USE (IEC_60559_BFP_EXT)
^
1 error generated.

ええ、そう思っていた時代が私にもありました。救世主だと勝手に思っていましたが、まさかのコンパイルできず。

注意

いずれの手順も CC=clang を付けなければ(=GCC を使えば)成功することは確かめていますが、私の実行したビルド手順が正しい保証はありません。

GCC → clang への切り替えを行う際に「CC=clang を付ける」が正しい手順とは限らないからです。ソフトウェアによっては clang 専用に別のビルド手順が存在するかもしれません。

ビルド失敗していることからもわかる通り、私は正しいビルド手順は発見できていません。知っていたらぜひ教えて欲しいです……。

メモ: 技術系の話は Facebook から転記しておくことにした。いろいろ追記した。

[編集者: すずき]
[更新: 2019年 3月 31日 23:10]
link 編集する

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link permalink

LLVM IR の作り方

いつも忘れるので、C 言語のコードから、オブジェクトコード、LLVM IR ビットコード、LLVM IR、アセンブラを生成する方法をメモしておきます。

C Source (.c) -> Object code (.o)

$ clang --target=riscv64 a.c -c -o a.o

C Source (.c) -> LLVM IR (.ll)

$ clang -c -S -emit-llvm a.c

C Source (.c) -> LLVM IR bitcode (.bc)

$ clang -c -emit-llvm a.c

LLVM IR (.ll) -> Assembly code (.S)

$ llc --march=riscv32 a.ll

LLVM IR (.ll) -> Object code (.o)

$ llc --march=riscv32 -filetype=obj a.ll
[編集者: すずき]
[更新: 2019年 3月 29日 23:00]
link 編集する

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link permalink

マンガ紹介

こわもてかわもて(1巻)(アマゾンへのリンク

子育ては奥さんにまかせきりで子供の扱いが良くわからない「こわもて」の爺ちゃん龍之介と、突然帰ってきた「かわもて」の孫の虎々(ことら)のコメディマンガ。

虎々のフリーダム加減は、よつばと!に似てるけど、周りの大人のキャラが違うので、作品としてはそんなに似てない気がする。今後が楽しみ。

マンガ紹介 その 2

我が驍勇(ぎょうゆう)にふるえよ天地〜アレクシス帝国興隆記〜(2巻)(アマゾンへのリンク

自国の貴族の罠により、故郷を隣国に攻め落とされ、親しい人も帰るべき地も失った王子が、英雄となり新たな帝国を築く(たぶん、タイトルから推測して)。王道の戦記物です。

主人公は不幸な生い立ちですが、復讐の鬼にはならず、器のデカさを感じます。2巻の時点ではまだまだ序盤ですから、今後はわからないですけども。画も迫力あっていい感じです。今後が楽しみです。

タイトルは最近あまり見ない厳つい感じですね。

異世界転生物に多いのですが、
「〜したら〜でした」
「〜が〜なんですが」
「〜は〜します」
のような説明的なタイトルって、個人的には冗長であまり好きじゃないです。面白いんだから、大丈夫だよ!もっと自信もって言い切って!!なんてことを思います。

その点、この本はタイトルからして目に留まって、とても印象的でした。

[編集者: すずき]
[更新: 2019年 3月 29日 22:48]
link 編集する

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link permalink

Clang の main 関数ってどこ?

ふと Clang の main 関数ってどこにあるんだろう?と思って、grep したのですが、それらしい箇所がありません。

GDB で Clang の main にブレーク掛けてみると、llvm/tools/clang/tools/driver/driver.cpp がヒットしました。んん?clang ディレクトリではなく、llvm ディレクトリにあるんですか?ちょっと初見ではわかりませんでした。GDB ありがとう。

Clang というか LLVM の困ったところは、シンボルが多すぎて GDB の起動に数分かかることです。GDB がメモリを 1.5GB ほど使うのも特徴的です。デバッグのために 1GB メモリを使うなんて今まで見たことありません。

この時点で既に低性能 PC お断り感がビシビシ出ていますが、LLVM の極めつけはリンク時にリンカがメモリ 8GB も使う(しかも 1プロセスで)ことです。

その辺のショボい PC ではデバッグがどうこう言う前に、そもそもビルドできず門前払いです。LLVM ムチャクチャが過ぎる……。

RISC-V 向け LLVM ビルド)

LLVM には RISC-V 向けの実装があるのですが、デフォルトでは有効になっていないようです。LLVM の CMakeLists.txt の LLVM_ALL_TARGETS に RISCV を足します。

LLVM の RISCV 向け実装を有効にする

diff --git a/CMakeLists.txt b/CMakeLists.txt
index ee6b77990b3..ce8f24afad1 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -327,6 +327,7 @@ set(LLVM_ALL_TARGETS
   MSP430
   NVPTX
   PowerPC
+  RISCV
   Sparc
   SystemZ
   WebAssembly

ビルドすれば RISC-V 用の LLVM やツールチェーンがビルドできます。

リンク時のメモリ節約方法(特定アーキテクチャ向け LLVM ビルド)

LLVM は何も指定せずにビルドすると、対応可能な全てのアーキテクチャに対応したバイナリをビルドしようとします。ビルドがメチャクチャ遅いので、cmake に LLVM_TARGETS_TO_BUILD でビルド対象を 1つだけに制限すると、ビルド、特に最後のリンクが速くなります。

RISCV のみをデバッグシンボル付きでビルドする
$ cmake -G Ninja \
  -D LLVM_TARGETS_TO_BUILD="RISCV" \
  -D CMAKE_C_COMPILER=clang \
  -D CMAKE_CXX_COMPILER=clang++ \
  -D LLVM_USE_LINKER=gold \
  -D CMAKE_BUILD_TYPE=RelWithDebInfo \
  -D LLVM_ENABLE_ASSERTIONS=ON \
  ../llvm

$ ninja

CMAKE_BUILD_TYPE に渡せる値は何種類かあります。Debug だとリンク時間がバカみたいに長く、リビルドが辛いです。Release だとビルドは速いですがデバッガがほぼ使えず、デバッグが辛いです。リリース相当だけどデバッグシンボルは付ける RelWithDebInfo が普段遣いには良いかもしれません。

メモ: 技術系の話は Facebook から転記しておくことにした。いろいろ追記した。

[編集者: すずき]
[更新: 2019年 3月 27日 22:06]
link 編集する

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link もっと前
   2019年 4月 5日 -
      2019年 3月 27日  
link もっと後

管理用メニュー

link 記事を新規作成

合計:  counter total
本日:  counter today

link About www.katsuster.net
RDF ファイル RSS 1.0
QR コード QR コード

最終更新: 4/20 00:42

カレンダー

<2019>
<<<04>>>
-123456
78910111213
14151617181920
21222324252627
282930----

最近のコメント 5件

  • link 19年04月01日
    すずき 「どの CPU というかシステムでも同じ傾...」
    (更新:04/05 11:03)
  • link 19年04月01日
    hdk 「去年Ryzen 7 1700で測りました...」
    (更新:04/02 22:48)
  • link 19年03月05日
    すずき 「> オシロの波形見てて気がつかなか...」
    (更新:03/21 17:45)
  • link 19年03月05日
    kml 「> 自分が持っている RockPr...」
    (更新:03/20 21:30)
  • link 19年03月10日
    すずき 「ありがとー!!」
    (更新:03/13 09:46)

最近の記事 3件

link もっとみる
  • link 19年04月19日
    すずき 「[RISC-V の SoC を見ていた] Linux が動くくらい...」
    (更新:04/20 00:42)
  • link 19年04月18日
    すずき 「[Linux の DMA] 昨今のキャッシュを持った CPU では...」
    (更新:04/20 00:29)
  • link 19年04月13日
    すずき 「[レジスタダンプ、書き換えツール memaccess - ちょ] ...」
    (更新:04/19 23:35)

こんてんつ

open/close wiki
open/close Java API

過去の日記

open/close 2002年
open/close 2003年
open/close 2004年
open/close 2005年
open/close 2006年
open/close 2007年
open/close 2008年
open/close 2009年
open/close 2010年
open/close 2011年
open/close 2012年
open/close 2013年
open/close 2014年
open/close 2015年
open/close 2016年
open/close 2017年
open/close 2018年
open/close 2019年
open/close 過去日記について

その他の情報

open/close アクセス統計
open/close サーバ一覧
open/close サイトの情報