アカウント名:
パスワード:
armのディープラーニングライブラリーを書くよりもx86→armのJITを書くほうが簡単なのか？というかintel謹製の「高速化」ライブラリーってx86の内部構造に依存した最適化がしてあるだろうしarm命令に置き換えても性能が出るものなんだろうか
①色々な言語のフレームワークによるインタフェース部分→②インテル謹製（というべきか？）のフレームワークによるコード生成→③実演算部分と言う感じの構成になってて、②のところに手を突っ込んでArmv8.3-Aで動くようにしよう。的な話と受け取りましたけど。
②から先の部分は、GPU使うならGPUで動く最適化された奴が用意されてるけど、富岳のArmv8.3-Aは今までなかったアーキテクチャなので、自力で移植するしかなかった。と言う話で。で、ここをArmネイティブで最初から書こうと思ったけど、②の検証工数が半端なく多くなることが判明し、信頼性を確保するのが困難と判断して、「だったら、最初にx64で吐かれたコードをArm向けに変換してやればいいじゃないか」と言う話になったって感じですね。コロンブスの卵みたいな感じ。
何しろ、②の部分が吐くx64向けのコードが多岐にわたるようで、大きなコードになると１万ステップを超える上に、日々進化してるので、それに追随して移植しながら検証もやってく。と言うのがコスト的に無理筋だと判断した感じですね。
で、> というかintel謹製の「高速化」ライブラリーってx86の内部構造に依存した最適化がしてあるだろうし> arm命令に置き換えても性能が出るものなんだろうか
そこは、JITコンパイラと言うか事実上のバイナリトランスレータのレイアで（個別の命令対応や文脈依存での対応を）最適化してよしとしましょうという感じのようですね。実際、既存の演算ライブラリと比べて二桁倍に迫るかそれ以上のパフォーマンスを既に叩き出してるようなので。
Xbyak開発者の方の記事を見るに、intelのoneDNN自体が対象CPUの条件に合わせてJITするコードをゴリゴリにチューニングするらしいです。トランスレートのオーバーヘッド含めてA64FXにて速くなる条件でJITさせるんでしょうね。トランスレート先で使いたい拡張命令と同等の計算内容となるx64拡張命令がありさえすれば、レジスタの数やらキャッシュサイズやらの影響はoneDNN側で合わせ込んでいけるのでしょう。その辺はintel CPUの中でも揃ってはいないですしね。
しかし、Xbyakって今ではintelが採用して相互協力するような物になってたんですね。初めて見かけた時は結構なアレゲ感でまさかこんなに信頼を得た使われ方するとは……特にintelってコンパイラ技術はかなりのレベルで内製してたはずだから、外部のを採用するよりむしろ自社製のを外に出す側だと思い込んでいました。Xbyakに食わす前のレイヤでの最適化はその流れも汲んでいるのでしょうけれど…
いろんな意味で意外かつ面白いニュースですね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
海軍に入るくらいなら海賊になった方がいい -- Steven Paul Jobs
コスパええの？ (スコア:0)
armのディープラーニングライブラリーを書くよりもx86→armのJITを書くほうが簡単なのか？
というかintel謹製の「高速化」ライブラリーってx86の内部構造に依存した最適化がしてあるだろうし
arm命令に置き換えても性能が出るものなんだろうか
Re:コスパええの？ (スコア:1)
①色々な言語のフレームワークによるインタフェース部分
→②インテル謹製（というべきか？）のフレームワークによるコード生成
→③実演算部分
と言う感じの構成になってて、
②のところに手を突っ込んでArmv8.3-Aで動くようにしよう。的な話と受け取りましたけど。
②から先の部分は、GPU使うならGPUで動く最適化された奴が用意されてるけど、富岳のArmv8.3-Aは今までなかったアーキテクチャなので、自力で移植するしかなかった。と言う話で。
で、ここをArmネイティブで最初から書こうと思ったけど、②の検証工数が半端なく多くなることが判明し、信頼性を確保するのが困難と判断して、「だったら、最初にx64で吐かれたコードをArm向けに変換してやればいいじゃないか」と言う話になったって感じですね。コロンブスの卵みたいな感じ。
何しろ、②の部分が吐くx64向けのコードが多岐にわたるようで、大きなコードになると１万ステップを超える上に、日々進化してるので、それに追随して移植しながら検証もやってく。と言うのがコスト的に無理筋だと判断した感じですね。
で、
> というかintel謹製の「高速化」ライブラリーってx86の内部構造に依存した最適化がしてあるだろうし
> arm命令に置き換えても性能が出るものなんだろうか
そこは、JITコンパイラと言うか事実上のバイナリトランスレータのレイアで（個別の命令対応や文脈依存での対応を）最適化してよしとしましょうという感じのようですね。実際、既存の演算ライブラリと比べて二桁倍に迫るかそれ以上のパフォーマンスを既に叩き出してるようなので。
Re: (スコア:0)
Xbyak開発者の方の記事を見るに、intelのoneDNN自体が
対象CPUの条件に合わせてJITするコードをゴリゴリにチューニングするらしいです。
トランスレートのオーバーヘッド含めてA64FXにて速くなる条件でJITさせるんでしょうね。
トランスレート先で使いたい拡張命令と同等の計算内容となるx64拡張命令がありさえすれば、
レジスタの数やらキャッシュサイズやらの影響はoneDNN側で合わせ込んでいけるのでしょう。
その辺はintel CPUの中でも揃ってはいないですしね。
しかし、Xbyakって今ではintelが採用して相互協力するような物になってたんですね。
初めて見かけた時は結構なアレゲ感でまさかこんなに信頼を得た使われ方するとは……
特にintelってコンパイラ技術はかなりのレベルで内製してたはずだから、
外部のを採用するよりむしろ自社製のを外に出す側だと思い込んでいました。
Xbyakに食わす前のレイヤでの最適化はその流れも汲んでいるのでしょうけれど…
いろんな意味で意外かつ面白いニュースですね。