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