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

ESP32やArduino系で走る「レイ・トレーシング」プログラムがある。

これを、RX65Nで、どのくらいのパフォーマンスなのか知りたくて、ポートしてみた。

元プログラムはC++で書かれたもので、良くできている。
※ソースコードは、ココから拝借したが、多少修正してある。
※ポーティングは極めて簡単だった。
RXマイコンは、浮動小数点の演算には定評があるので、少し期待していた。

結果は7.7秒と、まずまずの値ではある。
※速度比較の為、解像度320×240でレンダリングしている。

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

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 でほとんど差が出ないが、バイナリーサイズは多少異なっている。

カテゴリー: ソフトウェアー・エンジニアリング, 電子工作な日々 パーマリンク

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

  1. anon のコメント:

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

    • hira のコメント:

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

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

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

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

  2. sum のコメント:

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

    • hira のコメント:

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

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

    • hira のコメント:

      補足:
      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 を使っています。コメントデータの処理方法の詳細はこちらをご覧ください