パスワードを忘れた? アカウント作成
14990286 story
スパコン

スパコン富岳のAIスタック、開発者が誕生秘話を公開 30

ストーリー by nagazou
うまくやった感 部門より
あるAnonymous Coward 曰く、

富士通研究所が自社blogにて富岳用ディープラーニングライブラリの内側を公開している(富士通研究所の技術ブログ)。

これがなかなかに面白い内容で、Intelが公開しているx86向けディープラーニング高速化ライブラリをつかってJIT技術で動的にarm命令に変換、世界最高性能を達成したとのこと。普通ならIntelが激怒しそうな内容であるが、同時にIntelと成果をIntelのoneDNNにマージすることが合意され、今後は本家oneDNNがx86向けとarm向けの両方を管理するとのこと。

gihyo.jpでも本件のインタビュー記事が公開、共同開発のサイボウズ・ラボからも内部技術Xbyakの開発者よりコメントが寄せられている

  • by Anonymous Coward on 2020年11月19日 13時06分 (#3926853)

    タレコミ人も書いていますが、富士通らしからぬざっくばらんとした内容で面白い文書になっています
    ・oneDNN を Armv8-A 上で動かすために、Xbyak_aarch64 を開発して、更に JIT(Xbyak_translator_aarch64)を開発してしまう
    ・Xbyak_translator_aarch64 のコードネームが「開闢補完計画」
    ・oneDNN をマージするために Intel(アメリカ)とやりとりしていたら、ARM(イギリス)担当者も呼び出されて時差が凄い

    どれも OSS として公開したり本家にマージしたりと成果の還元も余念がありません

    あと気になったのは

    今時、アセンブラレベルの実装を理解しながらコーディング作業ができる人材を豊富に集められる状況にもありません

    で富士通なら古参の人材抱えていそうなものですが、「現代のアセンブラ」みたいな条件を満たせないって事ですかね
    こういった人材ってどの分野・会社あたりにいるんだろう……

    ここに返信
    • by Anonymous Coward

      組み込みあたりじゃないですかね
      Cを高級アセンブラとして使っている感覚
      あるいはパイプラインを手動充填最適化
      パズルを解くみたいで面白いと思えるなら天職だと思いますよ
      ええ

    • by Anonymous Coward

      人間はどれだけ引っ張ってもいつかは定年退職するから…

    • by Anonymous Coward

      > で富士通なら古参の人材抱えていそうなものですが
       
      大手メーカーは昔から自分でコード書いたりはせず、パワポと外注管理とかがメインだから。

      • by Anonymous Coward

        今回のは研究所なのでバリバリコードを書く人何人もいますよ。

    • by Anonymous Coward

      古参の人材は赤尾泰氏のように経営に回って会社を傾けているから...

    • by Anonymous Coward

      >富士通らしからぬざっくばらん
      kosakiさん?と思ったらそうだった。最近Twitterで見ないなと思ったら、がちゃぴんアイコンやめてたのか。

    • by Anonymous Coward

      自分の知り合いだと、昔アセンブラ書いてた人はFPGAのRTL書いたりCUDA書いたりしてます。
      高級なCPU向けだと今回のストーリーと同じで、ごく一部を除いてコンパイラ側で何とかなってしまう時代ですからね。

  • by Anonymous Coward on 2020年11月19日 12時20分 (#3926819)

    > Intelが公開しているx86向けディープラーニング高速化ライブラリをつかってJIT技術で動的にarm命令に変換

    同じ仕組みでApple Silicon上でも動かせるんですかね

    ここに返信
    • by Anonymous Coward

      Apple SiliconはArmv8.3-AらしいからDarwin固有の部分を移植すれば動くんじゃないかな?

      • by Anonymous Coward

        記事を読めばわかるが、ASにはHPC命令が実装されてないからダメ。

        • by Anonymous Coward

          記事を読んだ上で書いたんだけどな

          > AndroidスマホやiPhoneはArmv8-A命令セットを採用したCPU (ただし、SVE命令は非対応)が載っています。したがって、Xbyak_aarch64を使って生成するArmv8-A命令セットの実行コードを動かすことができるということです。

          Xbyak_aarch64がSVE命令を使わないようにJITコンパイルするんでしょ。速度は知らんけど。

    • by Anonymous Coward

      それなんてRosetta 2
      Apple Silicon使うなら素直にニューラルエンジン使うことを考えた方がいいのでは

  • by Anonymous Coward on 2020年11月19日 12時38分 (#3926835)

    こりゃIntelが腑甲斐ないからと殿様商売やってたらAMDもおちぶれるな。

    # Apple成分抜きのARM PCの登場が待たれる。

    ここに返信
    • by Anonymous Coward

      > # Apple成分抜きのARM PCの登場が待たれる。

      Surface Pro Xではだめなのでしょうか?

      • by Anonymous Coward

        全然ダメだよ。性能的にはApple M1の半分止まりな上に、Microsoftがタブレットより上位の機種でARMをやる兆候が全然ないじゃん。
        Appleが危機感を持つくらいの性能のARM石をWindows PCベンダーに広くバラ撒いて貰わないと。

        • by Anonymous Coward

          Qualcomm

          おぉ。委託開発だったからな。

      • by Anonymous Coward

        M1でも動かないアプリの話をちらほら聞いたが、Surfaceも動かないアプリが割とある。
        そもそもM1が速いのってMac用に設計されてるからと聞いたけど。

  • by Anonymous Coward on 2020年11月19日 12時40分 (#3926837)

    armのディープラーニングライブラリーを書くよりもx86→armのJITを書くほうが簡単なのか?
    というかintel謹製の「高速化」ライブラリーってx86の内部構造に依存した最適化がしてあるだろうし
    arm命令に置き換えても性能が出るものなんだろうか

    ここに返信
    • ①色々な言語のフレームワークによるインタフェース部分
      →②インテル謹製(というべきか?)のフレームワークによるコード生成
      →③実演算部分
      と言う感じの構成になってて、
      ②のところに手を突っ込んでArmv8.3-Aで動くようにしよう。的な話と受け取りましたけど。

      ②から先の部分は、GPU使うならGPUで動く最適化された奴が用意されてるけど、富岳のArmv8.3-Aは今までなかったアーキテクチャなので、自力で移植するしかなかった。と言う話で。
      で、ここをArmネイティブで最初から書こうと思ったけど、②の検証工数が半端なく多くなることが判明し、信頼性を確保するのが困難と判断して、「だったら、最初にx64で吐かれたコードをArm向けに変換してやればいいじゃないか」と言う話になったって感じですね。コロンブスの卵みたいな感じ。

      何しろ、②の部分が吐くx64向けのコードが多岐にわたるようで、大きなコードになると1万ステップを超える上に、日々進化してるので、それに追随して移植しながら検証もやってく。と言うのがコスト的に無理筋だと判断した感じですね。

      で、
      > というかintel謹製の「高速化」ライブラリーってx86の内部構造に依存した最適化がしてあるだろうし
      > arm命令に置き換えても性能が出るものなんだろうか

      そこは、JITコンパイラと言うか事実上のバイナリトランスレータのレイアで(個別の命令対応や文脈依存での対応を)最適化してよしとしましょうという感じのようですね。実際、既存の演算ライブラリと比べて二桁倍に迫るかそれ以上のパフォーマンスを既に叩き出してるようなので。

      • by Anonymous Coward

        Xbyak開発者の方の記事を見るに、intelのoneDNN自体が
        対象CPUの条件に合わせてJITするコードをゴリゴリにチューニングするらしいです。
        トランスレートのオーバーヘッド含めてA64FXにて速くなる条件でJITさせるんでしょうね。
        トランスレート先で使いたい拡張命令と同等の計算内容となるx64拡張命令がありさえすれば、
        レジスタの数やらキャッシュサイズやらの影響はoneDNN側で合わせ込んでいけるのでしょう。
        その辺はintel CPUの中でも揃ってはいないですしね。

        しかし、Xbyakって今ではintelが採用して相互協力するような物になってたんですね。
        初めて見かけた時は結構なアレゲ感でまさかこんなに信頼を得た使われ方するとは……
        特にintelってコンパイラ技術はかなりのレベルで内製してたはずだから、
        外部のを採用するよりむしろ自社製のを外に出す側だと思い込んでいました。
        Xbyakに食わす前のレイヤでの最適化はその流れも汲んでいるのでしょうけれど…

        いろんな意味で意外かつ面白いニュースですね。

    • by Anonymous Coward

      > armのディープラーニングライブラリーを書くよりもx86→armのJITを書くほうが簡単なのか?

      記事読むとその辺に関する記述があるよ

    • by Anonymous Coward

      ソースが公開されていなかっただけでしょ。
      JITなら一度通れば、AI処理なんて基本繰り返しなんだから、ネイティブと変わらんようになるでしょ。

  • by Anonymous Coward on 2020年11月19日 12時56分 (#3926847)

    Intelくらいでかい会社のハードと計算ライブラリとセールスくらい離れた部門なら
    セールスが困ったところで計算ライブラリ開発部門は知ったこっちゃないだろ
    むしろハード部門が多少困るくらいなら予算が回ってくるまである

    ここに返信
  • by Anonymous Coward on 2020年11月19日 23時15分 (#3927360)

    こんな貢献できる人になりたかった(じっと手を見る)。

    ここに返信
  • by Anonymous Coward on 2020年11月21日 5時36分 (#3928233)
    ここに返信
    • by Anonymous Coward

      へるみさんの富士通との関わりはFM-TOWNSからじゃないんだろうか?(そういう話ではない)

typodupeerror

開いた括弧は必ず閉じる -- あるプログラマー

読み込み中...