KIT-RX65N、レイ・トレーサー

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のマクロを提供してくれた「」さんに感謝したい、ありがとうございます。

コンパイラのバージョン:

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」キーワードが適切にあれば問題無いと思う。
※他のプロジェクト(ファミコンエミュレーター、音楽再生など)も確認したが問題ない。

「KIT-RX65N、レイ・トレーサー」への5件のフィードバック

  1. STM32F7 と比較して桁違いに遅いみたいですが、sqrt の演算にコプロセッサを明示的に使用しているみたいですね(VFP?vsqrt.f32 s0,s0 )。sqrt() が頻出しているので(詳しくは読んでいませんが ドット毎に8 回ほど実行されている?)、レンダリング時間に大きな差が生まれるんでしょうね。
    また、#include “arm_math.h” で ARM の算術用ライブラリだと最適化がされているんでしょうかね?
    (ESP8266 しかもっていませんが、さらに遅い…)

    1. 私も、元ソースは、あまり詳しく読んでいません、単純な速度比較が目的なので。

      ただ、「sqrt」が、ハードロジックで実行されたとしても、感覚的に全体の10%も使われないと思います、それより圧倒的に「掛け算」が多いものと思います。
      ※sqrtは、レイと球の交差判定と、ベクトルの正規化くらいじゃないかと思います。
      ※元々、交差判定は、ある程度最適化されていて、バウンティングボックスにレイが入らないとsqrtは使われないと思います。

      なので、こんなに大きな差が出るとは思えませんので、単純にfloat演算速度の違いなのだと思っています。

      ※詳しくは、詳細なプロファイルにかけないと判りませんが・・・

  2.  RXコア用のGNUコンパイラー(gcc)はRX v2コアに最適化が不十分であり,
    ルネサスの純正のCコンパイラーを利用すればもっと高速な処理が可能と
    思います。
     ARM系のCortex-M7コアではgccの最適化がよくされておりベンチマークで
    良い結果となります。
     Cortex-M7コアはFPUがCortex-M4コアよりも強化されており,Cortex-M4コアで
    RayTracing処理を実行するとかなり遅いです。

    1. そうかもしれませんが、「純正Cコンパイラ」は有料で高価なので、一部の特殊な人(業務で使っている)以外は利用できないと思います、また、試用期間は短く、永続的に利用できないのですから、現状では、gcc を使うしか選択枠はありません。

      ※同じプログラムをルネサス純正コンパイラで走らせて、結果を教えて下さい。
      ※自分の感覚では、最適化に関して、ルネサスコンパイラの方が有利なのは当然
      と思えますが、そんなに大きな差が出るとも思えません。
      せいぜい10%くらいじゃないでしょうか?
      しかしこれは、実際に試してみないとわかりませんが・・・

    2. 補足:
      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」を入れる事で、より高速に動く場合等があるのですが・・・

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください