ESP32やArduino系で走る「レイ・トレーシング」プログラムがある。
これを、RX65Nで、どのくらいのパフォーマンスなのか知りたくて、ポートしてみた。
元プログラムはC++で書かれたもので、良くできている。
※ソースコードは、ココから拝借したが、多少修正してある。
※ポーティングは極めて簡単だった。
RXマイコンは、浮動小数点の演算には定評があるので、少し期待していた。結果は7.7秒と、まずまずの値ではある。※元ソースを大きく修正するとベンチマークにならないものの、いくつかの修正を行った。
追記(2018年11月16日):
・浮動小数点関係の関数をRXマイコンの専用命令で置き換えた(FSQRTにより、約1/2の改善)
・実数の定義を明示的に「float」に修正(改善は少ない)
・オリジナルでは、進捗割合(%表示)と、実時間表示があるので、それに対応
・時間計測用に1/1000(1ms)のタイマーを追加
・RX65Nのキャッシュを有効にした(約10%の改善)
以上の改修で、「3.1秒」まで改善した。
※一番利いているのは、平方根命令の変更
※ピクセルを描画しない場合、「2.1秒」となる。(これはあまり意味が無い)
※速度比較の為、解像度320×240でレンダリングしている。
追記(2018年11月18日):
・比較していたサイトのベンチマークと、条件が異なっているとの指摘から、やり直した。
※大本のソースでは「raysPerPixel = 4」だったので、その条件で行っていたが、実際のスケッチでは、「raysPerPixel = 1」で行っており、1/4のレンダリング時間になるようだ。
・その結果、「837ms」(0.8秒)と、かなり高速にレンダリングする事が判った。
この値は、200MHz動作のARM(STM32F7)の0.62秒より遅いものの、動作周波数が120MHzのRX65Nなので、十分良い値のように思う。
謝辞:
この問題を指摘してくれ、FSQRTのマクロを提供してくれた「fujita nozomu 」さんに感謝したい、ありがとうございます。
コンパイラのバージョン:
rx-elf-gcc (GCC) 6.4.0 Copyright (C) 2017 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
最適化は「O3」
-------
Raytracing with ESP32
上記リンクには、各マイコンのレンダリングにかかる時間が載っている。
ESP32(160MHz)は、13秒みたいなので、それより低速(120MHz)のRXマイコン
はそれなりに優秀なのだと思う。
ただ、「STM32F7 (200MHz) 0.62 秒」に比べると、かなり見劣りする結果かもしれない・・
※クロックを差し引いても、かなり遅い・・・
全ソースは、GitHub にある。
-------
macsbug, cbm80amiga さんありがとう~
追記:
gcc の最適化によってどのくらい違うのかを確認しておいた。
・古い gcc-4.9.4 も確認したかったが、constexpr 関係がコンパイルできずにエラーとなったので、
コンパイラは gcc-6.4.0 のままだ。
・ベンチマークは「目安だ」プログラムの性質により大きく異なる場合が多いし、ほんの少し条件が変
わるだけで、結果が逆転する場合もある。
・ルネサス純正Cコンパイラでも評価したいところだが、環境を揃える事が難しいので、実験をしてい
ないが、ネットの情報を見ると、浮動小数点が多い場合は、gcc の方が優秀な場合があるようだ・・
※コメント欄のリンクを参照
コンパイラ | 最適化オプション | レンダリング速度 | 実行サイズ |
---|---|---|---|
gcc-6.4.0 | -O3 | 7.7 | 140568 |
gcc-6.4.0 | -O2 | 7.7 | 128180 |
gcc-6.4.0 | -Os | 13.2 | 106584 |
・O2、O3 でほとんど差が出ないが、バイナリーサイズは多少異なっている。
追記:(2018年、11月3日)
RX65のハードウェアーマニュアルを眺めていたら、RX65にはROMキャッシュ制御ビットがあり、通常「Disable」になっている事が判った。
※「フラッシュメモリ」、「59.3.2 ROM キャッシュ許可レジスタ( ROMCE )」
このビットを有効にして、レンダリングをしてみた、そうすると「6.8秒」と10%くらい速度改善している。
一応、標準で「有効」にするように設定したが、「キャッシュ」有効により、正常動作しない「実装」もあるかもしれないので、少し評価を徹底したい・・
※「volatile」キーワードが適切にあれば問題無いと思う。
※他のプロジェクト(ファミコンエミュレーター、音楽再生など)も確認したが問題ない。
STM32F7 と比較して桁違いに遅いみたいですが、sqrt の演算にコプロセッサを明示的に使用しているみたいですね(VFP?vsqrt.f32 s0,s0 )。sqrt() が頻出しているので(詳しくは読んでいませんが ドット毎に8 回ほど実行されている?)、レンダリング時間に大きな差が生まれるんでしょうね。
また、#include “arm_math.h” で ARM の算術用ライブラリだと最適化がされているんでしょうかね?
(ESP8266 しかもっていませんが、さらに遅い…)
私も、元ソースは、あまり詳しく読んでいません、単純な速度比較が目的なので。
ただ、「sqrt」が、ハードロジックで実行されたとしても、感覚的に全体の10%も使われないと思います、それより圧倒的に「掛け算」が多いものと思います。
※sqrtは、レイと球の交差判定と、ベクトルの正規化くらいじゃないかと思います。
※元々、交差判定は、ある程度最適化されていて、バウンティングボックスにレイが入らないとsqrtは使われないと思います。
なので、こんなに大きな差が出るとは思えませんので、単純にfloat演算速度の違いなのだと思っています。
※詳しくは、詳細なプロファイルにかけないと判りませんが・・・
RXコア用のGNUコンパイラー(gcc)はRX v2コアに最適化が不十分であり,
ルネサスの純正のCコンパイラーを利用すればもっと高速な処理が可能と
思います。
ARM系のCortex-M7コアではgccの最適化がよくされておりベンチマークで
良い結果となります。
Cortex-M7コアはFPUがCortex-M4コアよりも強化されており,Cortex-M4コアで
RayTracing処理を実行するとかなり遅いです。
そうかもしれませんが、「純正Cコンパイラ」は有料で高価なので、一部の特殊な人(業務で使っている)以外は利用できないと思います、また、試用期間は短く、永続的に利用できないのですから、現状では、gcc を使うしか選択枠はありません。
※同じプログラムをルネサス純正コンパイラで走らせて、結果を教えて下さい。
※自分の感覚では、最適化に関して、ルネサスコンパイラの方が有利なのは当然
と思えますが、そんなに大きな差が出るとも思えません。
せいぜい10%くらいじゃないでしょうか?
しかしこれは、実際に試してみないとわかりませんが・・・
補足:
https://japan.renesasrulz.com/gr_user_forum_japanese/f/gr-sakura/1803/gnu-iar-rx
この記事はかなり古いですが、参考にはなります。
float が多用されるような場合は、むしろ gcc の方が優秀なのではないでしょうか?
また、現在 RX の gcc は 6.4.0 を使っており、 4.8 系より優秀な事は判っています。
ネガティブ要素としては、-O3 の最適化だと、バイナリーサイズが小さくならない事ですが、2MバイトまでOKなので全く問題ありません。
LLVM の知見を受けて、gcc の最適化に関する方針や考え方に変化が生まれています。
最近では、中間コード(仮想CPU)での最適化に効果があると、それは、全てのCPUで恩恵を受けるようになっています。
この流れは、加速しており、個別のCPUで最適化を行う理由が少なくなっています。
それでも、インテル系CPUなどでは、命令アライメントを揃える為にあえて「NOP」を入れる事で、より高速に動く場合等があるのですが・・・