コグノスケ

x86とARMとRISC-VでCoreMark対決

目次: RISC-V

CoreMarkを以前（2019年7月5日の日記参照）測りましたが、ARM系のGCCのバージョンを上げたのと、x86系と、RISC-V系のFU740の計測結果を追加しました。FU540の値は以前のままです。

x86_64

• AMD Ryzen 7 5700X / 3.4GHz Turbo 4.6GHz
• AMD Ryzen 9 3950X / 3.5GHz Turbo 4.7GHz
• AMD Ryzen 9 5900X / 3.4GHz Turbo 4.9GHz
• Intel Core i5 8250U / 1.6GHz Turbo 3.4GHz
• Intel Core i7 6700 / 3.4GHz Turbo 3.8GHz
• Intel Pentium J4205 / 1.5GHz Turbo 2.6GHz

AArch32/AArch64

• Amlogic A311D（Cortex-A73 / 2.2GHz x 4, Cortex-A53 / 1.8GHz x 2）
• Broadcom BCM2837（Cortex-A53 / 1.2GHz x 4, 32bit mode）
• Renesas RZ/V2H（Cortex-A55 / 1.1GHz x 4）
• Rockchip RK3288（Cortex-A17 / 1.8GHz x 4）
• Rockchip RK3328（Cortex-A53 / 1.3GHz x 4）
• Rockchip RK3399（Cortex-A72 / 1.8GHz x 2, Cortex-A53 / 1.4GHz x 4）
• Rockchip RK3566（Cortex-A55 / 1.6GHz x 4）
• Rockchip RK3588（Cortex-A76 / 2.4GHz x 4, Cortex-A55 / 1.8GHz x 4）

RISC-V

• NSITEXE NS31A（NS31A / 25MHz x 1）
• SiFive FU540（U54-MC / 1.0GHz x 4）
• SiFive FU740（U74-MC / 1.2GHz x 4）
• SpacemiT Key Stone M1（X60 / 1.8GHz x 8）
• StarFive JH7110（U74-MC / 1.5GHz x 4）

動作周波数については後述します。

測定条件と結果

コンパイル条件は下記の通りです。

• Ryzen 9 5900X: GCC-9.4.0 O2
• Ryzen 7 5700X: GCC-12.2.0 O2
• Ryzen 9 3950X: GCC-7.5.0 Ofast
• Core i7 6700: GCC-9.4.0 Ofast
• Core i5 8250U: GCC-11.2.0 Ofast
• Pentium J4205: GCC-10.2.1 Ofast
• A311D: GCC-9.4.0 Ofast
• RK3588, RK3566, RK3399, RK3328: GCC-10.2.1 Ofast
• RZ/V2H: GCC-13.2.0 Ofast
• RK3288: GCC-10.2.1 Ofast, 32bit
• BCM2837: GCC-8.3.0 Ofast, 32bit
• Key Stone M1: GCC-13.2.0 Ofast
• JH7110: GCC-11.3.0 Ofast
• FU740: GCC-10.2.0 Ofast
• FU540: GCC-8.3.0 Ofast
• NS31A: GCC-12.2.0 Ofast

Ryzen 7はなぜかO2よりOfastの方が遅かった（O2: 41946, Ofast: 40442）ので、O2の結果を採用しました。RK3399はCA72とCA53の2種類のコアがあるので、taskset 0x1 ./coremarkのように実行するコアを固定して計測しています。

CoreMarkのIterations/Secの結果はCPUの動作周波数の影響を受けてしまうため、CPUの性能比較をする際はIterations/SecをCPU動作周波数で割った値を使うことが多いです。

やはりx86系CPUの速さは圧倒的です。Ryzen 7は異次元の速さですし、ローエンド向けに思われがちなAtom系コアもARM Cortex-A72を圧倒しています。（12/28追記）Pentium J4205の動作周波数が間違っていた（1.5GHz → 2.6GHz）ので修正しました。

RISC-V勢はFU540（U54-MCコア）はかなり遅く、FU740（U74-MCコア）でやっとRK3328（Cortex-A53コア）などのSoCと並ぶくらいです。FU740を搭載したHiFive UnmatchedはPCと同じホームファクタのMini-ITXを採用しており、NVMe SSDやグラフィックカードが装着できる点などは非常に素晴らしいのですが……、PCの代わりに使用するとなると非力すぎて、RISC-V PCを名乗るにはまだ厳しそうですね。

CPU動作周波数の取得

LinuxでCPUの動作周波数を取得する方法は色々あって、イマイチ統一感がないですけれども、このベンチマークでは下記のようにしています。

• x86系: /proc/cpuinfoのcpu MHz欄
• ARM系: /sys/devices/system/cpu/cpuN/cpufreq/cpuinfo_cur_freq
• RISC-V系: SoC次第

FU740の動作周波数はCore PLL（/sys/kernel/debug/clk/corepll/clk_rateの値 = 1196000000）から得ました。ARM系はCPU周波数が負荷に応じて変化するため、yes > /dev/nullなどを起動してCPUに負荷をかけた状態で見ています。

もし私が何か勘違いしていてCPU動作周波数を間違えているとどうなるかというと、Coremark/MHzが間違った値になります。Iteration/Secは変わりません。

ブライトバンド

今日、東京や千葉で輪のような形で雨が降っていると教えてもらいました。本当だ……不思議な現象ですね。

降水量が輪の形になっている（松戸、取手、習志野の近辺）

この現象、調べてみると既に名前がついていて「ブライトバンド」と呼ぶそうです。かっこいい名前ですね。ブライトバンドについてはウェザーニュースの解説が非常にわかりやすかったです（参考: 秋田県の雨雲レーダーに映る 謎のドーナツ型の正体は？ - ウェザーニュース）。

詳しくはぜひウェザーニュースの解説を読んでいただきたいですが、簡単に言えばレーダーが融解層（雪→雨に変わる部分）を捉えて過剰に反応している状態で、実際には強い雨が降っているとは限らないとのこと。

動かないブライトバンド、動いてしまう予報

ブライトバンドが出ているときに降水量の過去情報を見ると、ブライトバンドは出たり消えたりするだけで、その場からほとんど動かないことがわかります。

降水量が輪の形になっている（松戸、取手、習志野の近辺）

30分経っても移動しない（松戸、取手、習志野の近辺のまま、横浜の輪は消えた）

天気予報システムはブライトバンド＝強い雨雲と解釈して予想をするようで、輪が他の雨雲とともに移動するような予報を出しています。気象の専門家ではないので「それが何か問題でも？」に対する答えは持ち合わせていませんが……。

1時間後の予報、輪が移動している（習志野の近辺が右に流れている）

ブライトバンドの付近での局所予報は少し食い違うかもしれませんが、過去情報と予報を見比べても特に破綻しているようには見えませんし、ブライトバンドを雨雲とみなそうが、無視しようが大勢に影響はないのでしょう。

自作OSの紹介その2 - デザイン

目次: 独自OS

最近、趣味＆趣味からの発展で仕事でも独自OSを作成しています。独自OSの設計目標は下記の通りです。

• できるだけ軽く、速くしたい
• できるだけ便利、手軽にしたい
• アクセラレータ向けに割り切る（汎用OSは目指さない）

最初の2つの項目は大抵トレードオフですが、3つ目の項目を活かして軽く＆便利を両立させることが狙いです。

アプローチ（アクセラレータ側）

「便利、手軽」の実現のため、ソースコードレベルの互換性の確保を目指します。具体的にはLinux用に書かれたソースコードをそのままアクセラレータ用にコンパイル＆実行できれば、プログラマから見てLinuxの使い勝手を実現できている、と言えるはずです。

一方で「軽く、速く」を実現するため、Linuxとのソース互換を目指しつつも、アクセラレータ向けに割り切った制限をいくつか設けます。

単一バイナリを実行

ユースケースに由来する制約です。別の仕事をしたいときはアクセラレータで実行するバイナリを切り替えます。

プロセスは未対応（常に1プロセス）

上記とほぼ同じ理由です。アクセラレータ上でマルチプロセスが連携するようなサーバーやGUIを動かしたい人はいないでしょう。

スレッドは対応

アクセラレータはマルチコアであることが多いため、スレッドの対応は必須です。

スレッド数はハードウェアスレッド数を上限とする

ソフトウェアのソースコード互換を大きく壊す可能性がありますが、機能と速度のバランスを目指しました。アクセラレータは計算が仕事であり、コア数以上のスレッド生成はオーバーヘッドが増え性能が下がるだけです。スレッド数の制御が困難な場合は、スレッドを自動的に扱うライブラリ（OpenMPなど）の利用もありでしょう。

ファイルシステム、言語対応などの機能は対応しない

コードサイズの縮小、実装期間の短縮のためです。対応すること自体に問題はないです、が、おそらく要らないと思います。

MMUや特権モードは使わない

連動して動的リンクなども未対応です。将来的には対応するかもしれませんが、必須ではありません。

これらの制限が妥当かどうか？について今は結論は出ないので、実装して使って問題があれば今後修正したいと思います。アクセラレータやOSに詳しい方々の意見も聞いてみたいです。

アプローチ（ホスト側）

アクセラレータに処理を依頼する際のインタフェースはいくつかありますが、いずれも定番ではなさそうです。今回はOpenCL風のAPIを採用しました。OpenCL規格に準拠はしませんが、ある程度（例えばclinfoに応答できる程度）のOpenCL APIを実装します（ホスト側のソースコードのリンク）。

ホストとアクセラレータ間のデータ移動や実行制御の方法も考える必要があります。ホスト側からアクセラレータ側に何か計算を依頼するケースと、もう一つアクセラレータ側のスタンドアローン実行（ホスト側から制御なしでアクセラレータ側のみ単独実行するモード）はデバッグの利便性を考えると、必須に近い機能です。

またホスト側に過度に依存しないように、ホスト側のAPIが気に入らなくなったら別のAPIを実装することができるように、アクセラレータ側の独自OSとは別のリポジトリに分離して実装します。

実現方法

独自にOSを実装する道を選びました。既存のOSSを改造するより実装期間が短く済むと思ったくらいで、独自実装しなければならない強力な理由はないです。個人的な理由も入れて良ければ、独自OS実装に対する興味があったことが大きいです。

RTOSにLinux互換レイヤを積む方法、Linuxをダウンサイズする方法、などでも実現できるのではないでしょうか。Linuxをダウンサイズする方法だとスレッド周りの制約実現が難しいですかね……？やったことがないので何とも言えません。

そんなの簡単にできるよ、という方はぜひOS作成フレンズになりましょう。

独自OS - まとめリンク

目次: 独自OS

一覧が欲しくなったので作りました。

• 自作OSの紹介その1 - 概要
• 自作OSの紹介その2 - デザイン
• 何もない組み込み環境でDOOMを動かす - その4 - 自作OSの組み込み環境へ移植

自作OSの紹介その1 - 概要

目次: 独自OS

最近、趣味＆趣味からの発展で仕事でも独自OSを作成しています。OSと呼ぶほどの機能はありませんが、位置的にはCライブラリよりハード寄りのいわゆるOSレイヤーです（ソースコードへのリンク）。

目的、目標

想定する動作環境は、複数プロセッサで構成されたシステムにおいて、片方がホスト、もう片方がアクセラレータとして動作する環境です。想定する制御方法は、ホスト側で実行したくない、時間がかかる処理をアクセラレータ側に任せて終わるのを待つ、シンプルなユースケースで下記のようになります。

アクセラレータの制御方法

このようなシステムにおいてPC系のプログラマが気軽にアクセラレータ側のソフトウェアを書ける環境が欲しい、という発想から、アクセラレータのプログラマの補助となるようなOSの作成が目的です。

独自OSの設計目標は下記の通りです。

• できるだけ軽く、速くしたい
• できるだけ便利、手軽にしたい
• アクセラレータ向けに割り切る（汎用OSは目指さない）

最初の2つの項目は大抵トレードオフですが、3つ目の項目を活かして軽く＆便利を両立させることが狙いです。

既存手法との違い

アクセラレータを動作させるという観点で見れば、わざわざ独自OSを作成せずとも既存のアクセラレータ用言語を使ったり、既存OSの転用でも動作させることができます。

既存のアクセラレータ用言語、CUDAやOpenCLですね。速度は最高だと思います。プログラマ視点から見ると、これら言語の習得には若干手間が掛かります。

LinuxなどPC系OSを転用する場合、使い勝手はPCそのものなので最高でしょう。しかしアクセラレータ向けとしては大規模で大げさでもあり、ハードウェアのリソース特にメモリがかなり必要です。

RTOSを転用するの場合、省メモリかつ大抵の実装は速度も速いです。しかし目的が違う（リアルタイム処理を記述するためのOS）ため、色々なOS独自ルールが存在します。PC系のプログラマには馴染みが薄いです。

独自OSでは使い慣れたC/C++ 言語が使えて、速さを殺さず、Linuxの使い勝手を可能な限り両立させることを目指します。

個人で自社製品RISC-V CPUを買うことはできるか？その6 - 受領書と付属DVDの謎

目次: RISC-V

NS31A Entry Kitを受け取ったら受領書を送り返してほしい、と言われているのですが、受領書は不思議な書類で、

• B2B方式（納品書兼検査票、納品荷札、受領書の3つ）のまま来た、何を送り返せば良いか？
• 受領書の送付先に名古屋（私は東京在住）の住所が印字されている、おかしくないか？
• 印鑑をつくところがたくさん（検査、受入、受領印）あるが、どれが必要なのか？
• 受け渡し「場所」に私の個人名が印字されているが、これで正しいのか？

受領書に関係していそうな前者2つについて質問したところ「あなたの住所を書いてくれ」という意味が分からん回答が返ってきました。質問の仕方が悪いのか、的の外し方から察するに「私に何を送ったか把握していない」可能性もありそうです。

• メールのやり取りで「関係者」という単語が何度か出ていた → 窓口担当以外に、少なくとも発送担当が別に居る
• 発送担当はいつもの相手（デンソーかなんか）と勘違いしていた
• 窓口担当者は荷物をノーチェックで発送した

と推理すると包装の問題とか、個人向け販売なのに受領書がB2B向け販売の仕様（検査票＋受領票とセット）が少しは理解できます。

さておき質問を文章で説明するのは厳しそうなので、送られてきた書類をスキャンし赤い字で「ここですけど、どうしたら？」と書いて送ってみました。これならご理解いただけるはず。

中身が

付属していたDVDに書かれたデータも欠けていた（サンプルプログラムが入っていない）ので、問い合わせたら「内容が間違ってた、ごめん」的な返事とともに、後日DVDがもう1枚家に送られてきました。

個人向け販売チャネル第一号ってのはなかなか大変ですね。デバッグをしているような気分です。