北森瓦版 - Northwood Blog (Author : 北森八雲. Since July 10, 2006.)
Intel's New AVX10 Brings AVX-512 Capabilities to E-Cores(Tom's Hardware)
Intel reveals AVX10 instruction set, an evolution of AVX512 with support for Performance and Efficient cores(VideoCardz)
Intel Details APX - Advanced Performance Extensions(Phoronix)
Introducing Intel(R) Advanced Performance Extensions (Intel(R) APX)(Intel)

Intelは7月25日、Advanced Perfomance Extensions (APX) を明らかにし、またAVX512をP-coreとE-coreで統合してサポートできるようにしたAVX10を明らかにした。
現行の“Alder Lake”や“Raptor Lake”はP-coreとE-coreの対応命令の違いにより全体としてはAVX512命令に対応できないという難点があったが、今回のAVX10はそれを解決するものとなる。
 
AVX10は現行のCPUでのサポートは行われないようで、今後のCPUでのサポートとなる。IntelによるとAVX10は、今後のコンシューマ向けおよびサーバー向けProcessorの両方にとって最適なVector ISAになるだろうと述べている。

AVX10はE-coreとP-coreがAVX512をサポートできるようにするためのものである。P-coreがAVX512をサポートし、512-bit命令群はP-coreのみが実行でき、一方256-bit AVX10はP-coreとE-core両方で実行できる。Processor全体としてはAVX512をサポートできるという形となる。

もう少し深掘りすると、AVX10はAVX512のスーパーセットである。そして、そして256-bitないしは512-bitのvector register sizeを有するProcessorにおけるAVX-512 ISAの全ての機能を内包している。
AVX10 ISAはAVX512 VL featue flagを有するAVX512ベクタ命令を含む。最大ベクタ長が256-bit、そして8つの32-bit mask registerと新しいバージョンの256-bit命令をサポートする。このバージョンはP-coreとE-coreの両方で動作できる。
E-coreのAVX10の最大ベクタ長が256-bitでP-coreが512-bitであるという状況は、ArmのSVEを想起させる。


※ここの訳はかなり怪しい。256-bitベクタ長にとどまるE-coreと512-bitのP-coreの両方でAVX512をハンドリングできる、あるいはProcessor全体としてAVX512命令を実行できるようにするためのものがAVX10ということだと思うのだが・・・。

AVX10はAVX10.1とAVX10.2があり、AVX10.1は512-bitベクタ命令のサポートのみにとどまり、新しい256-bitベクタ長のカバーまでは行っていない。P-coreのみで実装される模様で、いわば本実装の準備段階のようなものらしい。AVX10.2で256-bitベクタ長のサポートとその他の機能が追加され、本実装となるようだ。
AVX10.1は“Granite Rapids”よりサポートされるとある。

IntelはまたAdvanced Perfomance Extensions (APX) を明らかにしている。
IntelによるとAPXを使用したコードは同様のIntel 64コードに対し、Loadが10%、Storeが20%削減されるとある。Intelによるとレジスタへのアクセス複雑なLoad and Store operationsに対して高速化するともに大幅な消費電力の低減を実現するという。APXには新しく128Bのエリアが使われており、これは2019年にIntelが打ち切ったMPXの分があり、またXSAVEも転用されている。


こちらはAPXに関して。とはいえ理解はさっぱりなので、適宜Intelの資料を当たって欲しい(なんかレジスタが16から32に増えたとか、LoadとStoreが減少して省電力化・高速化するとか)
関連記事



○Amazon売れ筋ランキング CPU メモリ グラフィックカード マザーボード SSD 電源

コメント
この記事へのコメント
196521 
Intelの図ではXeon PhiやTiger Lakeが書いてないから新しいCPUはそれまでの全てのAVX-512命令に対応してるように見えるけど、本当に全てのAVX-512命令に対応するの?
2023/07/26(Wed) 05:44 | URL | LGA774 #-[ 編集]
196522 
誤:Load and Store operationsに対して拘束でアルトともに
正:Load and Store operationsに対して高速であるとともに

さておきRaptorLake-Refreshで命令セットの変更とDLVRの導入により、
同じ電力で性能大幅アップ、とかなら面白いけど命令セットの変更はさすがにないか。
2023/07/26(Wed) 06:17 | URL | LGA774 #-[ 編集]
196526 
素人考えで将来的にはEコアにAVX512を実装してCPU全体でAVX512に対応するのかと思ってたら
AVX10なるもので現状の課題を解決するのか
EコアにAVX512を直接?実装するのはいろいろ問題があるのだろうか…この辺りの知識はさっぱり
2023/07/26(Wed) 08:08 | URL | LGA774 #-[ 編集]
196527 
Eコアしか無いやつはどうすれば
2023/07/26(Wed) 09:35 | URL | LGA774 #-[ 編集]
196531 
マスクレジスタとかあるから、ArmのSVEと似た考えなんだろうな。
初代AVXにデコーダ並列性目的のVEXが導入されたんだが、APXもそういう類かな。当初は多くの命令をVEX対応にして旧命令を亡き者にしていくのかなと思ってたけど、12年経った現在そういう世界になってなさそうだし。
Tom'sの「ソフト開発者の反応は明らかに消極的(だろう)」には笑った。またLinusにご意見いただきましょうかね。
で、AVX10の10はどこから?
2023/07/26(Wed) 11:53 | URL | LGA774 #-[ 編集]
196536 
AMDはZen7ぐらいで対応かな?
2023/07/26(Wed) 13:48 | URL | LGA774 #-[ 編集]
196537 
奥歯に物が挟まった言い回しでいまいち理解しづらいんだけど、これつまり
AVX512は失敗だったから次くらいは互換性のために残すけど次の次くらいで廃止するよ
新しいAVX10ではコアごとに256bitと512bitで分かれてることがあるから頑張って場合分けするプログラム書いてね
ってこと…?
2023/07/26(Wed) 14:19 | URL | LGA774 #-[ 編集]
196539 
>>拘束でアルト
なんてマニアックな(違
高速であると
かな?
2023/07/26(Wed) 15:31 | URL | LGA774 #-[ 編集]
196541 
まぁ実際にどこまで効果があるかはともかく、ARMやらRISC-Vの攻勢で、x86陣営としても命令セットそのものへのテコ入れが必要だった、ということだろうか。

確かIntel64はほぼ20年が経過するが、意地悪な見方をすれば、AMDに主導権を握られた64bit拡張で20年越しのリベンジを狙う、という意味もあるのかもしれない。いや、もちろんそんなつもりはないと思うけど、どうしてもそういう意味付けをしてしまう。
2023/07/26(Wed) 21:12 | URL | LGA774 #-[ 編集]
196542 
AVX10.2に期待。E-coreでどんなふうに実装されるのですかね。

E-coreで512-bitのベクトル命令を実行するときには、演算のスループットが半分になるとかですかね。
2023/07/26(Wed) 22:13 | URL | LGA774 #-[ 編集]
196544 
APXのほうは分かり易い。x64で廃止された旧AAD命令の1バイトをプリフィクスとして使い,整数演算用の汎用レジスタを32個まで拡張する。
命令実行後にフラグを変化させないことも選択可能になり,CMOV命令やSET命令を連続して使用することが可能になる。
また3オペランド命令にも対応。これはAVX512で使うEVEXプリフィクスを拡張して,スカラ整数演算に対応させたもの。

インテルの第16世代CPUはシングル性能を30~40%も引き上げるとされているが,これらの新命令の効果も含まれているのだろう。
2023/07/27(Thu) 00:54 | URL | LGA774 #sSHoJftA[ 編集]
196550 
>>196544
新命令対応のコンパイラで生成したバイナリを使った場合には30~40%で、従来のバイナリそのままだとIPCベースでは数%とかな気がしないでもない。
2023/07/27(Thu) 05:33 | URL | LGA774 #-[ 編集]
196551 
以前から、ベクトル演算についてCPUとGPUはどこで棲み分けるのか、と疑問に思っていたんだが、今回で一区切りがついたのかな、という気がする。

今後、製造プロセス次第で話が変わるのかもしれないが、事実上256bitまでがCPUの領域ということでしょう。512bit(言い換えれば単精度16Way)以上をCPU側に実装するのは効率的でなかったということでしょうね。

一部の方が妄想しているであろう「E-Coreへの512bit実装」は、これでほぼ可能性ゼロになったと思います。
2023/07/27(Thu) 05:37 | URL | LGA774 #-[ 編集]
196553 
>AMDはZen7ぐらいで対応かな?
intelが捨てた状態の今は、Zen4でAVX512自体対応済みだから面白い
2023/07/27(Thu) 08:59 | URL | LGA774 #-[ 編集]
196554 
> 一部の方が妄想しているであろう「E-Coreへの512bit実装」は、これでほぼ可能性ゼロになったと思います。

『Supported on P-cores, E-cores』
って書いてあったのを、勘違い。

ちゃんと
『Optional 512-bit FP/Int』
って書いてありますね。
2023/07/27(Thu) 09:34 | URL | LGA774 #-[ 編集]
196556 
>196527
ArmのSVEと同じ考え方なら、256bit 2回回し。768bit(出ないだろうが)なら3回、1024bitなら4回。
違いは将来出るかもしれない(Xeonはあり得る)1024bitや2048bit前提コードを今から書け(るはず)、コード変更不要になる。
2023/07/27(Thu) 11:23 | URL | LGA774 #-[ 編集]
196557 
APXはすごいな、プレフィックスのオーバーヘッドを許容すれば可変長命令の柔軟性のおかげでRISC命令そのものを実装できちゃうと。
2023/07/27(Thu) 12:08 | URL | LGA774 #-[ 編集]
196559 
AVX2+ と命名すると予想したけど、外した
2023/07/27(Thu) 13:13 | URL | LGA774 #-[ 編集]
196561 
>196551
一部の方が期待してるのはEコア無しorほぼEコアのメニーコアであって、
Eコア能増はその隙間に落ちて誰も望んで無い気がします
2023/07/27(Thu) 19:07 | URL | LGA774 #-[ 編集]
196562 
AVX10はIntelのEコアのような機能削減コアを持たないAMDには今のところ関係ないですね
将来機能削減コアを作るタイミングでIntelの試みが上手く言ってたら対応するんじゃないですか
2023/07/27(Thu) 23:21 | URL | LGA774 #-[ 編集]
196563 
APX ですが、汎用レジスタ増やすんですね。

レジスタ・リネーミングがあるから、増やす必要はないのかと思ってました。

コンパイラの最適化とかの事情でしょうかね?
2023/07/27(Thu) 23:34 | URL | LGA774 #-[ 編集]
196565 
>196537
いや、CPUがAVX10に対応するということはそのCPUはAVX512にも対応している。
スーパーセットってそういうもの。
2023/07/28(Fri) 01:50 | URL | LGA774 #-[ 編集]
196566 
>196557
それはRISC/CISCともに台無しな使い方かと
2023/07/28(Fri) 02:02 | URL | LGA774 #-[ 編集]
196568 
AVX10は一過性の処置で…と思ったけっどAVX512に限らず、将来的にEコアの命令セット拡張されたとしても
Pコアの命令セットがさらに拡張されたら命令セット格差は続くわけで、あっても損はしない感じか
2023/07/28(Fri) 08:10 | URL | LGA774 #-[ 編集]
196572 
>196531
>10はどこから?
なんとかうまく数え方を工夫すれば…。SSEから数えるとかして、
1: SSE
2: SSE2
3: SSE3
4: SSSE3
5: SSE4.1
6: SSE4.2
7: AVX
8: AVX2
9: AVX512
10: ←今ココ
でどうだ。
2023/07/28(Fri) 11:51 | URL | LGA774 #-[ 編集]
196574 
>>196563
コンパイラの最適化によりループアンローリングを施すと,汎用レジスタがもっと欲しくなります。
2023/07/28(Fri) 12:14 | URL | LGA774 #sSHoJftA[ 編集]
196576 
196562
Zenの場合はintelと違って面倒なこと何も無いしAVX512をAVX10でラップするだけですぐに対応させるのでは
ただこの機能が要るのはEPYCではなくRyzenなのでAMDのその辺の温度感は微妙だけど
2023/07/28(Fri) 17:59 | URL | LGA774 #-[ 編集]
196587 
> 196574
汎用レジスタの数を arm とかに合わせておかないと、コンパイラのメンテナンスとか色々不都合なんですかね。(arm は31個みたいです)
2023/07/29(Sat) 12:23 | URL | LGA774 #-[ 編集]
196588 
汎用レジスタをx86からAMD64で8から16に増やしときにはクロックはどんどん上げられると思ってたけど、発熱でクロックを上げられなくなったから汎用レジスタを32に増やしたときのデメリットを無視できるようになったのかな、64への増加も考えた方がいいんじゃない
2023/07/29(Sat) 13:47 | URL | LGA774 #-[ 編集]
196595 
>>196588
乱暴に言えば、レジスタはキャッシュより上位の超高速なメモリに過ぎない。
あくまで演算リソースの補助機構であって、演算自体は行わない。
従って、ここがボトルネックにならないうちは、増やす意味がない。
ちなみに性格上追加のコストはキャッシュより大きいと考えるのが妥当。

現在x86系で一番重厚なGoldenCoveはALU×5の構成。
恐らく、このレベルでようやくボトルネックになる可能性が見え始めたのだと考える。
ここで32本に増加すれば、ヘッドルームは相応に引き上がるだろう。
ということは64本へ増加する意味は当面ない。
2023/07/29(Sat) 22:31 | URL | LGA774 #-[ 編集]
196596 
>>196574
京はsparcを魔拡張してレジスタを128とか256とか指定できるようにして性能を引き上げたらしいから、性能のためとにかく増やすという方向もありえそう

多くのRISCみたいに命令が32bit固定長だとビット数的にレジスタ数は32個とかせいぜい64個が限界だけれども、X86は命令が可変長だからその気になればいくらでもレジスタ数を増やせるし、どうせ物理レジスタは200個くらいあるはずだから、32個でとどめる理由は何か別にあるのかな
2023/07/29(Sat) 23:33 | URL | LGA774 #-[ 編集]
196603 
レジスタスピルしなくてよくなるから、レジスタ数は多ければ多いほど性能向上するのでは?

GPU なんかは、汎用レジスタが数千個とかあって、演算ユニット当たりで言っても CPU よりも全然多い。

スレッド実行に必要なデータは全部レジスタに置いて、D$ になんかはアクセスしていないと思う。
2023/07/30(Sun) 09:51 | URL | LGA774 #-[ 編集]
196604 
> 196574 
> コンパイラの最適化によりループアンローリングを施すと,

ループアンローリングできるコードなら、ベクトルコンパイラで自動ベクトル化できるので、
それで AVX のベクトル長を伸ばすのかと思っていたけど、、結局 256bit どまりでしたね

期待しけどダメだったもの2選:

1.AVX-512
2.Intel TSX(←これ、何処に行っちゃったの?もう帰ってこない?)
2023/07/30(Sun) 10:05 | URL | LGA774 #-[ 編集]
196608 
>196596
>どうせ物理レジスタは200個くらいあるはずだから、32個でとどめる理由は何か別にあるのかな
ALUsとレジスタファイルの間の配線が莫大になるからでしょうか?(でもそれは、レジスタ・リネーミングでも同じような??)
2023/07/30(Sun) 17:45 | URL | LGA774 #-[ 編集]
196609 
自分は素人ですが、さすがに「レジスタは多ければ多いほどいい」は安直だと思う。
2023/07/30(Sun) 18:36 | URL | LGA774 #-[ 編集]
196610 
AVX10って要するにISAとしては既存のAVX512命令系そのままサポートするけど
MAとして見ると512bitのint/fpを馬鹿正直に実装しなくても良いようにコンパクトな(おもにEコアのために)実装を可能としたものってことか
2023/07/31(Mon) 03:14 | URL | LGA774 #-[ 編集]
196613 
Intel TSXはセキュリティがなぁ
なんならHyperthreadingまでdisableするとかいう噂だし

そんなバカなと思ったけどEコアあるからPコアにHT要らないという考え方もあるかも知れない
2023/07/31(Mon) 09:41 | URL | LGA774 #-[ 編集]
196614 
>196565
ところがそのsupersetって書いてるTom'sの記事の下の方に、
「全ての将来のXeonプロセッサはレガシーアプリが普通に動作するのを保証するために全てのAVX-512命令の完全なサポートを続ける」
とか書いてあるんだな。
つまりXeon以外ではAVX-512命令をサポートしないことができるわけで、スーパーセットってのは言葉のアヤじゃないかなって思う。
「AVX-512でできることはAVX10でもできる」とか。
(ところでAll future Xeon processorsというけど2,3世代後に「Xeon」をやめましたとかやりそう)
2023/07/31(Mon) 13:16 | URL | LGA774 #-[ 編集]
196615 
>196614
マスゴミじゃあるまいし計算機科学の用語に言葉のアヤなんて恣意的なものはないよ
集合に含まれないならばsupersetではなくextendedとかenhanced setでしかない
2023/07/31(Mon) 19:45 | URL | LGA774 #-[ 編集]
196624 
>>196608
考えて見たらSMTがあるから1スレッドあたりの物理レジスタは100個くらいのオーダーになるので、64個は多過ぎで32個くらいがちょうどいいということになるのかもしれないですね
2023/08/01(Tue) 02:14 | URL | LGA774 #-[ 編集]
196650 
>196624
RISC-Vも32本の汎用レジスタを持つみたいです。きっとそのあたりが、
バランスが良い設計なんですね。

GPUと違って、
CPUは一度レジスタをインストラクションセットから見えるようにしたら、互換のため
ずっとサポートし続けなければならないので、慎重に決定するのでしょうね。

レジスタ割り当てをコンパイラがやる→実行時にレジスタ・リネーミングでいじる、と
ずいぶん複雑なことをしていますね。
2023/08/02(Wed) 10:51 | URL | LGA774 #-[ 編集]
196652 
>196615
言葉のアヤが恣意的というのはよくわかりません。人間誰にでもミスはあるものでしょう。
特に、Intel自身の発言ではなくそれを伝えるマスコミであるTom'sがなにかミスをするのはよりありえそうなことです。
何にせよ、1つの記事の上と下で内容が矛盾して見えるので、どこか(私の理解含め)に間違いがあるのだろうと考えるしか無いのですが、supersetという言葉の使い方がミスである以外に何か納得の行く解釈はあるでしょうか。
2023/08/02(Wed) 12:17 | URL | LGA774 #-[ 編集]
196686 
どれくらいちゃんとした superset なのか、今後注目ですが、
もし Intel がちゃんとやれないとすると、
もう技術的なことをちゃんとやれないところまで、会社が落ちっていってしまっているんでしょうね。
残念ですが。。

(最初に使った Intel CPU は、8085/8086 でした。盛者必衰の、、本当に、残念ですが。)
2023/08/05(Sat) 22:34 | URL | LGA774 #-[ 編集]
196693 
>196686
8086/8088 ではなく 8085/8086 なのがちょっと凄いと思った。
2023/08/06(Sun) 15:50 | URL | LGA774 #sSHoJftA[ 編集]
196714 
>196566
そんなこと言われてもIntelは実際そうしようとしてるし俺に言われても困るな
2023/08/08(Tue) 00:46 | URL | LGA774 #-[ 編集]
コメントを投稿する(投稿されたコメントは承認後表示されます)