IntelのPonte Vecchio

IntelのPonte Vecchio(Photo14)に関しては、アーキテクチャに関しては2021年のIntel Architecture Daysで、パッケージに関してはHot Chips 33で説明されている。こちらでその辺をまとめてレポートしているので、ここからのUpdateという形でレポートしたいと思う。

  • Pat Gelsinger CEO

    Photo14:これは基調講演のセッションで、Ponte Vecchioを示すPat Gelsinger CEO

まずコアの性能について。Ponte VecchioのXe-Coreでは、Vector Engineは8つに減っており、その代わりに個々のEngineは512bit幅を扱える様になっている。コンシューマ向けGPUのXe-Coreを2つ合体させたような感じだ。

目的は以前も書いたように、AVX512にあわせて512bitのデータ幅を扱える様にしたためと思われる。個々のXe-CoreはVectorが256Flops(FP32/64)、Matrixが2048(TF32)/4096(FP16/BF16) Ops or 8192(INT8) Opsとなっており、1 SliceにXe-Coreが16個、1ダイに4 Slice+L2+HBMコントローラ+Media Engine+XeLinkが付属し、このダイが2つでPonte Vecchioが構成される。つまりPonte Vecchioには128個のXe-Coreが搭載される計算だ。ここから逆算すると、Ponte Vecchioの動作周波数は1.7GHz程度を想定していると考えられる。

  • Photo15:これまでは、FP32で45TFlops以上、という漠然とした数字しか示されていなかった

    Photo15:これまでは、FP32で45TFlops以上、という漠然とした数字しか示されていなかった

また今回キャッシュおよびメモリの帯域も示された(Photo16)。Rambo Cacheは8 Tile構成なので、つまりTileあたり51MBという中々面白い容量になっている。L2をRambo Cacheとして別チップに追い出した最大の理由は容量を大きく取れる事だという(Photo17)。

  • alt属性はこちら

    Photo16:ここで言うL2は、RAMBO cacheとして説明されてきたもの

  • DNNだとそうでもない

    Photo17:DNNだとそうでもないが、猛烈な量の転置(=猛烈なランダムアクセス)が発生するFFTでは性能の向上ぶりが凄い。それはともかく、ResNet-50の実際のスコアが示されないのは何故？

またMatrixエンジンの効率についても紹介された(Photo18)。特に行列のサイズが大きくなると、効率が95％程度まで向上するとするのは、逆に言うと大規模な行列を扱わないと効率が猛烈に悪いという話で、このあたりは使い方を工夫する事が求められる格好だ。

  • 512×512だと効率が40％弱

    Photo18:なんでサイズが小さいと効率が悪いかというと、恐らくはレジスタへのデータ転送のオーバーヘッドが大きくなるためだと思われる。とはいえ、512×512だと効率が40％弱というのは、流石にどうだろう？ という気はする

また今回発表された話で言えば、Ponte VecchioではSIMD以外にSPMD/SIMTでの使い方が可能という話だ。GPU的に言えばSPMD/SIMTの方が自然だが、既存のCPU上で動くコードをPonte Vecchioに移植するのであればSIMDの方が使いやすい。SPMD/SIMTとSIMDでどの程度性能が変わるか？　は(コードの書き方次第という事もあってか)今回は開示されなかった。

  • プログラムの容易さでは、一番左のSPMDが楽である

    Photo19:プログラムの容易さでは、一番左のSPMDが楽である。ただ性能が上がるのか？　という疑問はあるが

ただCPU上で動くSIMDのコードをPonte Vecchioに持ってゆくと4倍程度に性能が上がる、という話は示された(Photo20)。

  • SIMDのままだとどこまで性能が上がるのかは不明

    Photo20:CPUのSIMDコードをPonte VecchioのSIMDにまず持ってゆき、そこからSIMTに最適化した結果が4倍という話なので、SIMDのままだとどこまで性能が上がるのかは不明

絶対性能と言う意味では、NVIDIAのA100と比較した結果がこちら(Photo21)。

  • Image Denoisingだと4割増し程度でしかない

    Photo21:もっともアプリケーションによって性能向上率は異なる。Image Denoisingだと4割増し程度でしかない

A100上でCUDAを使った場合を基準にした場合で、Ponte Vecchioだと最大2.5倍程度の性能が得られるとしている。もう少しアプリケーション寄りではminiBUDE(Photo22)、ExaSMRのNekRS(Photo23)とOpenMC(Photo24)のスコアが示されており、いずれもA100を大幅に上回るとしているのだが、ただ登場時期を考えるとHopper H100が競合になると考えるべきで、そのHopperがA100比で2～6倍(HPC向け)の性能である(と主張している)ことを考えると、Hopperと比べてどこまでPonte Vecchioにアドバンテージがあるのかちょっと判断が難しい。

  • OneAPI DPC++を利用しての性能例

    Photo22:OneAPI DPC++を利用しての性能例

  • こちらもOneAPI DPC++を利用している

    Photo23:こちらもOneAPI DPC++を利用している

  • こちらはOpenMCを利用しての例

    Photo24:こちらはOpenMCを利用しての例

なおここで名前が出て来たOpenAPI DPC++はIntelがOneAPIの提供に合わせて提供されているもの(以前はData Parallel C++と呼んでいたが最近はDPC++が正式名称になっている様だ)だが、SYCLをサポートしており、基本はこれでプログラミングする事でポータビリティと性能を確保できる(SYCLそのものはChronos Groupが仕様を定めているオープン規格である)という目論見である。

ただCUDAで記述されたアプリケーションがHPCの業界では非常に多い事から、これをSYCLに変換するDPC++ Compatibility ToolがIntelより提供されている(Photo25)。

  • 95％位ということは、20行に1行は手作業で変換が必要という事

    Photo25:95％位ということは、20行に1行は手作業で変換が必要という事で、つまりToolを使った出力をもう一度全部見直してやる必要があるレベルである。まぁそれでも全部手作業で変換するよりはマシだとは思うが

先のPhoto21とかはこれを利用しての結果と思われる。ただ自動変換されるのが90～95％というのは、正直あまり高い効率とは思えないあたり、もう少し頑張ってほしいところだ。

それはともかくとして、今回一番知りたかった(のに公開されなかった)のが消費電力である。AuroraのターゲットであるPeakで2EFlops超えを、どの程度で実現できるかである。報道によればAuroraのターゲットは60MWほどだそうで、効率を考えるとFrontierより相当悪い計算になる。1.7GHz駆動と目されるPonte Vecchioの消費電力、OAMを採用しているという事は700W以下に収まっていると思いたいのだが、そろそろ動作実績を紹介してほしいところである。