このブログは、株式会社フィックスターズのエンジニアが、あらゆるテーマについて自由に書いているブログです。
2017/06/06 一部内容を訂正しました。
Out Of Orderのプロセッサが一般的になってしまってからあまり使わなくなった、ソフトウェアパイプラインを考えてみようと思います。
In-Orderプロセッサの最適化経験がある方はご存知のことなので、最後のほうまで飛ばしてください。
まず、アフィン変換のような処理を見てみます。
各画素においてだいたい上から順に依存関係があるので、多少のことはコンパイラががんばってくれますが各演算のレイテンシが長いと、効率が悪く性能が出ません。
各演算のレイテンシを見える化すると下図のようになります。In-Orderプロセッサの場合、<の箇所でパイプラインが遊んでしまいます。
一方Out Of Orderプロセッサの場合、次の画素やその次の画素の処理を先に実行するため、下図のようにレイテンシで空いてしまった隙間に依存しない命令が入り、効率が上がります。下図では、画素の違いを色分けしています。
In-Orderプロセッサでは、こういった賢いことはやってくれないので、上図のような最適化を自分で書かないといけません。ここで使うテクニックがソフトウェアパイプラインです。
実際にソフトウェアパイプライン化したものが下図になります。
※下図では太字がループ外変数で、実際にはループ前にプロローグ処理が必要です。
この時のループボディだけを見てみましょう。
が実行されます。
図式化する都合で太字で示したループ外変数が複数の色を持っていますが、ループ内では不変なので、実体は1つです。
色分けしていなかったら3つの処理がどの行で実行されているのか全然わからないですね。
3つの処理を別々に書けたら、見やすくていいのに。。
そんな言語ありましたね。
同様の処理をVerilogで記述すると下図になります。
(2017/06/05 追記)メモリアクセスは上記モジュール外でAXIなどのバスを使うことを想定しています。
参照画素の読み出しはキャッシュがないと性能がでないとか細かいところはさておき、ハードウェア記述言語だと、簡単に見やすく書けますね。
さて、改めてソフトウェアパイプラインとハードウェア記述を比べてみましょう。
記述は違いますが、意外と近いところもあるんじゃないでしょうか。
ここまで、ソフトウェア最適化の観点から話を進めてきましたが、ソフトウェア最適化を忘れて、ソフトウェアパイプラインの段数を増やしていき、積和演算も分割していき、どんどん細かくしていきましょう。そうすると、ハードウェアの1サイクル分の処理が少なくなり、レイテンシ5サイクルの積和演算命令のハードウェア実装というのも想像できるのではないでしょうか。
コンピュータビジョンセミナーvol.2 開催のお知らせ - ニュース一覧 - 株式会社フィックスターズ in Realizing Self-Driving Cars with General-Purpose Processors 日本語版
[…] バージョンアップに伴い、オンラインセミナーを開催します。 本セミナーでは、...
【Docker】NVIDIA SDK Managerでエラー無く環境構築する【Jetson】 | マサキノート in NVIDIA SDK Manager on Dockerで快適なJetsonライフ
[…] 参考:https://proc-cpuinfo.fixstars.com/2019/06/nvidia-sdk-manager-on-docker/ […]...
Windowsカーネルドライバを自作してWinDbgで解析してみる① - かえるのほんだな in Windowsデバイスドライバの基本動作を確認する (1)
[…] 参考:Windowsデバイスドライバの基本動作を確認する (1) - Fixstars Tech Blog /proc/cpuinfo ...
2021年版G検定チートシート | エビワークス in ニューラルネットの共通フォーマット対決! NNEF vs ONNX
[…] ONNX(オニキス):Open Neural Network Exchange formatフレームワーク間のモデル変換ツー...
YOSHIFUJI Naoki in CUDAデバイスメモリもスマートポインタで管理したい
ありがとうございます。別に型にこだわる必要がないので、ユニバーサル参照を受けるよ...