コグノスケ

HiFive Unleashed の動作周波数

目次: RISC-V - まとめリンク

SiFive FU540 のコア動作周波数は簡単に見ることはできなかったので、求め方をメモしておきます。

アドレス 0x10000000 に PRCI（Power Reset Clocking Interrupt）のレジスタがありますので、実機でその辺をダンプします。

突然ダンプしますって言われても、どうしたら良いんですか？という方は拙作の memaccess（GitHub へのリンク）をお使いください。使い慣れたツールがあれば、RISC-V 上でビルドすれば使えます（Unleashed は Linux が動くので）。

私の持っている HiFive Unleashed では下記のようになっていました。

10000000 c0000000 82110ec0 00000000 82110dc0
10000010 80000000 00000000 00000000 82128ec0
10000020 80000000 00000000 0000002f 00000004

COREPLL 周波数を司るレジスタは、corepllcfg0（offset: 0x04）です。値は 0x82110ec0 ですね。

• [ 5: 0] divr = 0x0
• [14: 6] divf = 0x3b = 59
• [17:15] divq = 0x2
• [20:18] range = 3'b100 => 33MHz

レジスタの各フィールドはこんな意味になっています。計算式は、

COREPLL = 33.33MHz / (divr + 1) * 2 * (divf + 1) / 2 ^ divq

ですので、上記の値を当てはめますと、

COREPLL
= 33.33MHz / (0 + 1) * 2 * (59 + 1) / 2 ^ 2
= 33.33 * 120 / 4 = 999.99MHz ≒ 1GHz

すなわち 1GHz 駆動であることがわかります。

ウソは書いていないつもりですが、情報源が気になる方は FU540 の仕様書 "Chapter.7 Cloking and Reset" の章を見てください。

FU540 の仕様書は SiFive のサイト（FU540 のサイトへのリンク）から、誰でもゲットできます。ページの下側かつ左側にある "FU540-C000 Manual" と書いてあるリンクです。

ARM の場合は簡単

Unleashed は面倒でしたが、Rockchip 系（に限らないと思いますが）の SoC は /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_max_freq を見ると簡単に最大動作周波数を取得できます。

$ for i in /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_max_freq ; do echo $i; cat $i; done
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq
1296000
/sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_max_freq
1296000
/sys/devices/system/cpu/cpu2/cpufreq/cpuinfo_max_freq
1296000
/sys/devices/system/cpu/cpu3/cpufreq/cpuinfo_max_freq
1296000

$ for i in /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_max_freq ; do echo $i; cat $i; done
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq
1416000
/sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_max_freq
1416000
/sys/devices/system/cpu/cpu2/cpufreq/cpuinfo_max_freq
1416000
/sys/devices/system/cpu/cpu3/cpufreq/cpuinfo_max_freq
1416000
/sys/devices/system/cpu/cpu4/cpufreq/cpuinfo_max_freq
1800000
/sys/devices/system/cpu/cpu5/cpufreq/cpuinfo_max_freq
1800000

簡単で良いですね。こういう細かい使い勝手は RISC-V はこれからでしょうか。とはいえ世界は RISC-V 旋風が吹き荒れているそうなので、次第に充実していくことでしょう。

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

ARM と RISC-V で CoreMark 対決

目次: RISC-V - まとめリンク

先日購入した HiFive Unleashed が異様に遅く感じるので、手持ちの 64bit コア同士でベンチマーク対決をしてみました（2019年 12月 5日、Raspberry Pi 3 の結果を追記）。以前、モナコインのマイナーでベンチマークしたとき（2019年 5月 27日参照）は、Cortex-A53 の 1/4 くらいの性能でした。

• Rockchip RK3399（Cortex-A72 / 1.8GHz x 2, Cortex-A53 / 1.4GHz x 4）
• Rockchip RK3328（Cortex-A53 / 1.3GHz x 4）
• Broadcom BCM2837（Cortex-A53 / 1.2GHz x 4, 32bit mode）
• SiFive FU540（Rocket / 1GHz x 4）

ベンチマークは CoreMark を使いました。コンパイル条件は下記の通りです。

• RK3399, RK3328: GCC-6.3.0 Ofast
• BCM2837: GCC-6.3.0 Ofast, 32bit
• FU540: GCC-8.3.0 Ofast

RK3399, RK3328 は Debian arm64 Stable を使っています。Stable は RISC-V に対応していませんので、FU540 だけは Debian riscv64 Unstable を使っています。BCM2837 は Raspbian です。

測定の結果は、

• RK3399: Iterations/Sec : 10242.753252
• RK3328: Iterations/Sec : 4427.390791
• BCM2837: Iterations/Sec : 4008.016032
• FU540: Iterations/Sec : 2255.130422

RK3328 と FU540 は 2倍の差です。動作周波数の差は 1.3倍ですから、インオーダーのコア同士にしては性能差があります。

RK3399 は異様に速いです。もしかすると A72 側で動いているかもしれません。CoreMark は特定の CPU に張り付ける方法が良くわからないですね……。

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

Debian Buster が来た

いつもやっている apt-get dist-upgrade を実行して、ろくに読まずに Yes, Yes と適当に答えていたら、家のサーバーの Debian を Stretch から Buster にアップグレードしてしまいました。

アップグレードすること自体に何も悪い点はないですが、何も今日、刈谷のホテルからやる必要は全くなかったなあ、と反省しきりです。これで起動しなくなったら、明日の夜にアクセスできなくなって困りますね……。

今回は幸いなことに再起動後も元気に動作していたので、何ら被害はありませんでした。設定を大幅に弄っている場合など、たまに起動しなくなることがあるので、今後は遠隔地から大胆なアップデートをするのはやめておきます。

メモ: 技術系？の話は Facebook から転記しておくことにした。追記＆文を組み換えた。

OpenVX on OpenCL

目次: OpenCL を調べる - まとめリンク

会社の人に OpenVX の別実装があることを教えてもらったので、試してみました。

以前、ソフトウェア実装の OpenVX ライブラリを動かしました（2018年 11月 14日の日記参照）が、AMD の OpenVX の実装（GitHub へのリンク）を使うと、GPU で OpenVX を動かすことができます。

AMD の OpenVX 実装ではありますが、OpenCL を使うので GPU は Radeon である必要はなく、Intel の GPU でも OK です。これが共通 API たる OpenCL の良いところですね。私は現状 Radeon を持っていませんので、Intel の内蔵 GPU で動かしてみようと思います。

動かし方

まず OpenVX ライブラリをビルドします。Debian であれば opencl-c-headers 辺りが必要になるはずです。また GPU ドライバとして Intel GPU ドライバの OSS 実装である beignet を使います。Debian であれば beignet-dev, beignet-opencl-icd 辺りのパッケージでインストールできます。

$ git clone https://github.com/GPUOpen-ProfessionalCompute-Libraries/amdovx-core
$ cd amdovx-core

$ mkdir build
$ cd build
$ cmake ../
$ make -j4

テストには前回も活躍した OpenVX アプリを使用します。OpenCV のバージョンは 3.2 です。もし古いバージョンの OpenCV を使っている場合は -lopencv_videoio オプションを外してください（おそらく「そのようなライブラリは存在しない」とエラーが出る）。

g++ solution_exercise1.cpp -Wall -I../include \
  -lopencv_video -lopencv_videoio -lopencv_highgui -lopencv_imgproc -lopencv_core \
  -lopenvx -L/path/to/amdovx-core/build/lib

前回とほぼ同じですので、さほど難しくないと思います。

GPU の実力

ビルドできましたので、実行……をする前に、vxProcessGraph の前後に時間計測のコードを入れておきます。

diff --git a/tutorial_exercises/solution_exercise1/solution_exercise1.cpp b/tutorial_exercises/solution_exercise1/solution_exercise1.cpp
index c7b8e21..ebc07e5 100644
--- a/tutorial_exercises/solution_exercise1/solution_exercise1.cpp
+++ b/tutorial_exercises/solution_exercise1/solution_exercise1.cpp
@@ -30,6 +30,8 @@
  *          Kari Pulli             <kari.pulli@gmail.com>
  */
 
+#include <sys/time.h>
+
 ////////
 // Include OpenCV wrapper for image capture and display.
 #include "opencv_camera_display.h"
@@ -368,6 +370,8 @@ int main( int argc, char * argv[] )
     // Process the video sequence frame by frame until the end of sequence or aborted.
     for( int frame_index = 0; !gui.AbortRequested(); frame_index++ )
     {
+        struct timeval st, ed, el;
+
         ////////********
         // Copy the input RGB frame from OpenCV to OpenVX.
         // Use vxAccessImagePatch and vxCommitImagePatch APIs (see "VX/vx_api.h").
@@ -407,8 +411,11 @@ int main( int argc, char * argv[] )
         //      if the frame_index == 0 (i.e., the first frame of the video
         //      sequence), otherwise, select the feature tracking graph.
         //   2. Use ERROR_CHECK_STATUS for error checking.
+        gettimeofday(&st, NULL);
         ERROR_CHECK_STATUS( vxProcessGraph( frame_index == 0 ? graphHarris : graphTrack ) );
-
+        gettimeofday(&ed, NULL);
+        timersub(&ed, &st, &el);
+        printf("ProcessGraph:%d.%06d[s]\n", (int)el.tv_sec, (int)el.tv_usec);
 
         ////////********
         // To mark the keypoints in display, you need to access the output

実行環境は下記のとおりです。

• CPU: Pentium J4205/1.50GHz
• Mem: DDR3L-1600 8GB x 2
• GPU: Intel HD Graphics 505/250MHz（J4205 内蔵）

最初にソフトウェア版のライブラリを実行します。

$ LD_LIBRARY_PATH=/path/to/openvx1.1/out/LINUX/x86_64/release/ ./a.out

OK: FILE ../../tutorial_videos/PETS09-S1-L1-View001.avi 768x480
LOG: [ status = -1 ] Hello there!

ProcessGraph:0.254740[s]
ProcessGraph:0.183655[s]
ProcessGraph:0.181082[s]
ProcessGraph:0.180022[s]
ProcessGraph:0.182914[s]
ProcessGraph:0.180622[s]
...

最初のフレームは HarrisCorner による角検出、それ以降のフレームはトラッキングに要した時間です（そういう内容のデモです）。トラッキングに大体 180ms 程度、掛かっている様子がわかります。

次に内蔵 GPU で実行します。

$ DISPLAY=:1 LD_LIBRARY_PATH=/path/to/amdovx-core/build/lib ./a.out

OK: FILE ../../tutorial_videos/PETS09-S1-L1-View001.avi 768x480
LOG: [ status = -1 ] Hello there!

LOG: [ status = 0 ] OK: OpenVX using GPU device#0 (Intel(R) HD Graphics Broxton 0) [OpenCL 2.0 beignet 1.3] [SvmCaps 0 0]

ProcessGraph:0.030192[s]
ProcessGraph:0.016439[s]
ProcessGraph:0.015872[s]
ProcessGraph:0.015629[s]
ProcessGraph:0.015629[s]
ProcessGraph:0.015679[s]
...

トラッキングに 16ms 程度しか掛かりません。正直言って GPU としてはローエンドの下の方ですが、J4205 の CPU 処理と比較すると圧倒的に速いです。GPU 恐るべしですね。

埼玉を洪水から守る

首都圏外郭放水路 庄和排水機場（埼玉県春日部市）の調圧水槽と第一立坑（たてこう）の見学に行きました。

庄和排水機場の外観

首都圏外郭放水路とは、洪水多発地域の中川流域（埼玉県の東部）を洪水から保護するため、中川、綾瀬川といった中小河川の水を地下経由で引き込み、ポンプで引き上げて江戸川に放流する仕組みです。

首都圏外郭放水路の概要

ちなみに国の施設でして、管轄は国土交通省（サイトへのリンク）です。

見学

見学コースの一つである、調圧水槽は、地下神殿との呼び名もあるほどで、広大な空間とたくさんの柱があります。

柱の役割がわかっていなかったのですが、係の方の説明によると、周りの地下水の浮力で調圧水槽が浮き上がってしまうので、重い天井と柱で、水槽を下に押しつけているそうです。

調圧水槽

第一立坑は高さ 70mの大迫力で、一番上の壁沿いに組まれた足場から下を見ることができます。私は高いところが苦手でして、非常に怖かったです。足が進まないし、変な汗が止まりません。

怖すぎて壁際にずっとしがみついていたため、写真を撮る余裕がありませんでした。一緒に行ったみなさまが高いところが平気なようで、写真をバシバシ撮っていましたので、一枚恵んでもらいました。

第一立坑（たてこう）

高いところ（立坑）はもう懲り懲りですが……、今回参加したコースとは別の見学コース（排水ポンプ室に入れる）もあるらしいので、別コースにもぜひ行ってみたいですね。

除算命令

今まであまり CPU アーキテクチャの違いを感じたことはありませんが、除算命令を触っていたところ、アーキテクチャによってかなり動きが違っていて面白かったので、メモしておきます。

プログラムは下記のとおりです。

#include <stdio.h>
#include <limits.h>

void f(int a, int b)
{
        printf("mul:%08x * %08x = %08x\n", a, b, a * b);
        printf("div:%08x / %08 = %08x\n", a, b, a / b);
}

int main(int argc, char *argv[])
{
        f(INT_MAX, -1);
        f(INT_MIN + 1, -1);
        f(INT_MIN, -1);     //乗算、除算の動作は未定義
        f(INT_MAX, 0);      //除算の動作は未定義
}

初めに断っておくと、コメントを打った箇所については、C 言語上の仕様上、動作が未定義です。つまり、どんなことでも起こり得ます。不定な結果が返ることもあるし、プログラムが停止することだってあります。

未定義動作も色々

このプログラムを x86 (x86_64, Ryzen 7 2700), ARM (AArch64, Cortex A53), RISC-V (RV64GC, SiFive FU540) の Linux 上でそれぞれ実行してみます。

#### x86_64 ####

mul:7fffffff * ffffffff = 80000001
div:7fffffff / ffffffff = 80000001
mul:80000001 * ffffffff = 7fffffff
div:80000001 / ffffffff = 7fffffff
mul:80000000 * ffffffff = 80000000
Floating point exception


#### AArch64 ####

mul:7fffffff * ffffffff = 80000001
div:7fffffff / ffffffff = 80000001
mul:80000001 * ffffffff = 7fffffff
div:80000001 / ffffffff = 7fffffff
mul:80000000 * ffffffff = 80000000
div:80000000 / ffffffff = 80000000
mul:7fffffff * 00000000 = 00000000
div:7fffffff / 00000000 = 00000000


#### RV64GC ####

mul:7fffffff * ffffffff = 80000001
div:7fffffff / ffffffff = 80000001
mul:80000001 * ffffffff = 7fffffff
div:80000001 / ffffffff = 7fffffff
mul:80000000 * ffffffff = 80000000
div:80000000 / ffffffff = 80000000
mul:7fffffff * 00000000 = 00000000
div:7fffffff / 00000000 = ffffffff

当然ながら、動作が定義されている演算は、どのアーキテクチャでも同じ結果です。当たり前ですね。

• INT_MAX * (-1) = INT_MIN + 1
• INT_MAX / (-1) = INT_MIN + 1
• (INT_MIN + 1) * (-1) = INT_MAX
• (INT_MIN + 1) / (-1) = INT_MAX
• INT_MAX * 0 = 0

一方で動作が未定義の演算は、かなり挙動が変わります。

• INT_MIN * (-1) = INT_MIN
• INT_MIN / (-1) = クラッシュ (x86_64), INT_MIN (AArch64, RV64GC)
• INT_MAX / 0 = クラッシュ (x86_64), 0 (AArch64), -1 (RV64GC)

個性が出ますね。

x86 の除算命令の奇妙な仕様

先ほどの例で x86 上で INT_MIN / (-1) の除算がクラッシュする原因は idiv 命令の仕様です。

Intel の命令仕様書（Intel Architectures Software Developer Manual: Vol 2）の IDIV - Signed Divide のページを見ると、保護モード例外 #DE が発生する条件として、

• ソース・オペランド（除数）が 0 である場合
• デスティネーションに対して符号付きの結果（商）が大きすぎる場合

この 2条件が挙げられています。INT_MIN / (-1) は結果が 32bit で表現できないため、後者に引っ掛かるわけです。

異常な演算に対して例外を発生させる設計思想なら分かりますが、乗算命令は異常な結果でも素通しなのに、除算命令は異常な結果だと例外発生します。片手落ちの不思議な仕様です。変なの……。

RISC-V の命令

目次: RISC-V - まとめリンク

最近、何かと関わっている RISC-V の理解のため、エミュレータを書いてみています。先日購入した HiFive Unleashed（2019年 5月 26日の日記参照）の 1st ROM と 2nd ROM を拝借して、Linux がブートする辺りまで作るのが当面の目標です。

スクラッチから作ると辛いので、ARMv5 のエミュレータ ememu（GitHub へのリンク）をベースにして改造して作っています。まがりなりにも ARMv5 が動いているんだから、RISC-V も楽勝だろうと思いきや、世の中そんなに甘くありませんでした。

最初にコケたのは Unaligned な命令ロードです。RISC-V の C 拡張をサポートする場合 32bit 境界ではないアドレスから、32bit 命令をロードする場合があります。ARMv5 では Unaligned アクセス例外が発生します。

RISC-V の命令エンコード

まだ完成していないので、現時点での感想ですが、RISC-V の命令エンコードは比較的わかりやすい気がします。ただ、ブランチ命令のオフセットは、下記のような並びになっていて、不思議な配置です。

RISC-V のブランチ命令

今まで見た中で一番見づらいものは、C 拡張命令のバイナリです、これは異様に見づらいです。しかし C 拡張の目的（命令長を削るため 16bit 長に無理して詰めている）からすると、仕方ないでしょうね。

強いオセロ

どうやっても圧勝してしまう「最弱オセロ」（リンク）が話題ですが、実はその横に「強いオセロ」（リンク）もあります。URL から推測するにこちらの方が先に作られたように見えます。

名前に偽りはなく、ものすごく強いです。私のような素人の実力ですと 50石（ほぼ真っ白）〜64石（全て白）で完敗します。終盤に一気にひっくり返され、全く勝てません。

まともにやっても全く勝てなかったので、どんな手でも良いから、1度でも勝てないだろうか？と試行錯誤するうちに、ちょっとしたクセが見えてきました。この AI は「終盤の大逆転」を重視していて、序盤〜中盤は石数が不利でも無視する傾向があります。

このクセを逆手に取り、中盤戦でとにかくゴリ押しして、白を全滅させる作戦を取ると、ごくたまに勝てることがあります。下記はその例です。

中盤でゴリ押しして勝てたケース

中盤で押し切れなければ負けです。20〜30局やりましたが、これ以外の勝ち方はできませんでした……。

RISC-V 原典

RISC-V 原典という本も買って読んでいます。どちらかというと頭から読む本ではなく、辞書的な本です。命令一覧の章はとても便利ですね。

RISC-V 原典では「過去のアーキテクチャが患ったインクリメンタリズム」と他のアーキテクチャの複雑さを評していましたが、RISC-V は出来たばかりなので「今」シンプルなのは当然だよね……などと思ったりしました。

RISC-V と昔の ARM

RISC-V は命令セットの独自拡張を許しているため、同じ RISC-V CPU を名乗っていても「A社 CPU と B社 CPU では、同じバイナリが実行できない」ことがありえます。

ARM や x86 も互換性のない CPU は存在しますが、共通の命令セットが大きいためあまり問題にはなりません。一方 RISC-V は共通命令セットが小さい（RV32I、MMU なしのマイコンレベル）ので、非互換性で問題が起きそうですね。ARM でいうと Cortex-A 系と Cortex-M 系を混ぜて売るようなもので、混乱を招きそうです……。

このタイプの命令拡張方式で私が思い出したのは ARM です。ARM も昔は ARMv5TEJ のように、対応する拡張命令をアルファベットで追記する、似たような方式を採用していましたが、ARMv6 で拡張命令に全て対応したため、拡張命令方式は消滅しました。

未来予想

私の予想としては、スマートフォン、デジタル家電、PC のような、比較的高性能な分野には RV64GC（G = IMAFD、multiple, atomic, float, double）が共通命令セットになり、マイコン系には RV32I か IM くらいが共通命令セットになる、辺りが落としどころかなと思います。

RISC-V も「インクリメンタリズム」に陥る未来は避けられず、拡張に次ぐ拡張でゴチャゴチャになる未来を迎えると思いますが、20年後、

• RISC-V がそもそも使われているか
• RISC-V は今と同じことを言えるくらいシンプルを維持できるか
• RISC-V が別のアーキから同じ欠点を指摘されていないか（歴史は繰り返す…）

期待が大きいだけに、将来的にどうなるか、楽しみです。

ヘッドフォンの謎のノイズ

オーディオは専門ではないし、神の耳も持っていないので、細かい音質うんぬんは全くわからないし、高級○○ケーブルなどはオカルトの一種とすら思っていますが……。

音質で唯一体験したことを思い出したので、メモしておきます。

以前はテレビのファーム開発をしていたため、職場ではテストのために少し良い（1万円〜2万円レベルの）ヘッドホン（SHURE SRH440-A）を使っていました。

何も鳴らしていないのに、ヘッドホンからたまにブーン……という微かなノイズと、バリ、バリ！という大きめのノイズが聞こえていました。

スマホとヘッドフォン

最初、評価ボードか機材の故障を疑っていたのですが、なんと原因は自分のスマホでした。

前者のブーン……ノイズは、ヘッドホンのケーブルをくるくると丸めて束ねた上に、スマホを置いていたため、スマホの電波を拾ってノイズになっていたようです。

たまにしか鳴らないのは、パケット通信のときしか強く電波を発しないからですかね？スマホを机の上に置かないようにしたらノイズは聞こえなくなりました。

家の安いヘッドホンで同じことをしても、ノイズは聞こえなかったので、感度の良いヘッドホンじゃないと拾わない（？）のかもしれません。

後者のバリバリ！ノイズは、ヘッドホンアンプの上にスマホを置きっぱにしたときに鳴っていました。ノイズを増幅するのか、かなり目立つバリバリ音が聞こえていました。

これもスマホとアンプを遠ざけて置くことで、ノイズが消えました。

謎が解ければ何てこと無い原因でしたけど、最初はわからなくて、このヘッドフォン壊れているんだろうか？不良品かしら……？とか思っていました。冤罪でした、ごめんねヘッドホンさん。

タチの悪い内蔵音源

音質でもう一つ思い出したのが、先代ノート PC（ThinkPad Edge E420）のアナログオーディオ出力は、常にシューシューというノイズが聞こえていたことです。

2010年は遥かに過ぎて、こんなにノイズが鳴るオーディオがあるはずない、聞き間違いだろうと思いきや、安物のオシロで見てもすぐわかるくらいノイズが載っていてショックでした。Conexant さん勘弁してよ……と思いました。

測定結果は、以前の日記に書いています（2014年 10月 18日の日記参照）。あれからもう五年も経ったのか。早いものだ。

メモ: 技術系？の話は Facebook から転記しておくことにした。リンクなどを追記。