AMDのCDNA 3コンピュートアーキテクチャ
(chipsandcheese.com)- AMD CDNA 3は、CDNA 2がFP64スーパーコンピューティングでは成果を上げた一方で、H100と比べてAI性能と統合GPU規模で劣っていた点を補おうとするコンピュートGPUアーキテクチャである
- MI300Xは8基のXCDに合計304基のCompute Unitを搭載し、これを単一GPUのように見せることで、MI250Xのように2つのGPUと別個のメモリプールに処理を分散しなければならなかった負担を軽減している
- メモリ階層は256MBのInfinity Cache、XCDごとの4MB L2、CU近傍の32KB L1へと再構成され、理論上17.2TB/sのキャッシュ帯域幅を提供するが、統合メモリ構成ではdie-to-dieリンクがボトルネックになりうる
- 実行ユニットはFP32の活用率を高めるため、デュアルイシューに近い構造とSIMDごとに追跡可能なスレッド数の増加を導入し、行列演算のスループットも前世代のCDNAと比べてCUあたり2倍に増加した
- CDNA 3の中核的な変化はメモリ階層とパッケージングにあり、MI300Xは大幅に拡張されたInfinity Fabric帯域幅によって、複数のチップレットを1つの大型アクセラレータのように見せる設計となっている
CDNA 3が狙うギャップ
- AMDはGPUコンピュート市場でNvidiaに追いつくため、Terascale 3、GCN、CDNA/RDNA分離を経てアーキテクチャを進化させてきた
- CDNA 2ベースのMI250XとMI210は、ORNLのFrontierを含む複数のスーパーコンピュータ案件を獲得し、Frontierは2023年11月のTOP500で1位を獲得した
- CDNA 2はFP64コンピュートで堅実かつコスト効率の高い性能を示したが、H100はAI性能で優れ、より大規模な統合GPUを提供している
- CDNA 3は、AMDの先進パッケージング、Infinity Fabric、RDNA系のInfinity Cache、改良されたCompute Unitを組み合わせ、この差を縮める方向で設計された
MI300XのGPUレイアウト
- MI300Xは、コンピュートをAccelerator Complex Die(XCD) に分割したチップレット構造を採用している
- XCDは、CDNA 2/RDNA 3のGraphics Compute Die(GCD)やRyzenのCore Complex Die(CCD)に近い役割を担う
- CDNA製品にはRDNA系の専用グラフィックスハードウェアがないため、AMDが名称を変更したものと見られる
- 各XCDには物理的に40基のCDNA 3 Compute Unitがあり、MI300XではXCDごとに38基が有効化されている
- 1つのXCDには4MBのL2キャッシュがあり、そのダイ上のすべてのCUが利用する
- MI300Xは8基のXCDで合計304基のCompute Unitを提供する
- MI250Xの220基のCUから大きく増加しており、MI300XはこれらのCUを単一GPUとして見せることができる
- MI250Xでは各GPUが独立したメモリプールを持つため、プログラマが2つのGPUに処理を直接分配する必要があった
- Nvidia H100は132基のStreaming Multiprocessor(SM)を1つの統合GPUとして見せるが、コンピュートを大型単一ダイに実装する従来型の方式を用いている
- H100はL2を2つのインスタンスに分割しており、単一のSMは50MBのL2全体を利用できるが、25MBを超えるアクセスには性能ペナルティがある
- MI300XのXCDは他のXCDのL2容量をキャッシュに利用しないため、キャッシュ容量の活用という点ではNvidia方式の方が効率的である
Ponte Vecchioとの構造比較
- Intel Ponte Vecchio(PVC) はCompute Tileを基本コンピュートブロックとして使用しており、これはCDNA 3のXCDにおおむね対応する
- PVCのBase Tileは、CDNA 3のIOダイと似たように、大きな最終段キャッシュとHBMメモリコントローラを含む
- PVCカードもMI300Xと同様に、単一GPUと統合メモリプールとして見せることができる
- 両者の構造の違いは、チップレットのサイズ、キャッシュ配置、ダイ間リンクに表れている
- PVCのCompute Tileは8基のXe Coreで構成され、38基のCUを持つCDNA 3のXCDより小さい
- IntelはCompute Tile全体のキャッシュではなく、より大きなL1キャッシュによってcross-dieトラフィックの要求を減らしている
- 2スタックのPonte Vecchioを統合GPUとして使う場合、EMIBブリッジは230GB/sしか提供しないため、すべてのメモリコントローラへのアクセスをストライピングするとHBM帯域幅を完全には活用しにくい
- IntelはGPUをNUMA構成として扱えるAPIを提供している
- 物理構成では、CDNA 3はIOダイ間の高帯域幅を必要とする一方、PVCは低帯域幅のEMIBリンクで成立しているが、4種類のダイタイプと異なるプロセス・ファウンドリの組み合わせにより設計は複雑である
- MI300Xは2種類のダイタイプのみを使用し、6nmと5nmのいずれもTSMCプロセスである
Infinity Cacheとメモリボトルネック
- コンピュート性能は数十年にわたりメモリより速いペースで向上しており、GPUもCPUと同様により高度なキャッシュ戦略でこれに対応してきた
- CDNA 2は8MB L2とHBM2eに依存する従来型の2段キャッシュ階層を採用していたが、MI250XはNvidia H100よりも帯域幅不足が大きかった
- CDNA 3は、RDNA 2から持ち込まれたInfinity Cacheを追加している
- MI300のInfinity Cacheは、技術文書ではMemory Attached Last Level(MALL)と呼ばれるメモリ側キャッシュである
- L1・L2よりもCompute Unitから遠く、メモリコントローラに接続されている
- すべてのメモリトラフィックがInfinity Cacheを通過し、IOトラフィックやpeer GPU通信もInfinity Cache帯域幅の恩恵を受けられる
- DRAM内容の最新状態を常に把握しているため、snoopのようなキャッシュ維持処理を行う必要がない
- メモリ側キャッシュは一般にレイテンシが高いため、AMDはCDNA 3とRDNA 2の両方で複数MB級のL2キャッシュによりCompute Unitを保護している
Infinity Cache容量と理論帯域幅
- CDNA 3のInfinity Cacheは、RDNA 2と同様に16-way set associative構造である
- CDNA 3の実装は、容量よりも帯域幅に最適化されている
- 128個のsliceで構成される
- sliceあたりの容量は2MB、読み取り帯域幅は1サイクルあたり64バイトである
- 全slice合計で1サイクルあたり8192バイトを提供し、2.1GHzでは17.2TB/sに相当する
- RDNA 2の128MB Infinity Cacheは、全slice合計で1サイクルあたり1024バイト、2.5GHzで理論上2.5TB/sを提供する
- die shotsによれば、RDNA 2のInfinity Cache sliceは4MB容量と1サイクルあたり32バイトを提供しているように見える
- MI300Xは、compute densityの低いワークロードでもInfinity Cache hitが十分に得られれば良好な性能を発揮できる
- Infinity Cacheの理論帯域幅でrooflineモデルを組むと、MI300Xはロードした1バイトあたり4.75 FLOPsで全FP64スループットに到達できる
- DRAMのみを使う場合は、ロードした1バイトあたり14.6〜15 FLOPsが必要となる
Cross-die帯域幅の制約
- MI300XのInfinity Fabricは4基のIOダイにまたがっており、各IOダイは2つのHBM stackと関連するキャッシュパーティションに接続されている
- MI300Xが統合メモリプールを備えた単一の論理GPUとして動作する場合、die-to-die接続帯域幅がInfinity Cacheの理論最大帯域幅の達成を制限する可能性がある
- 単一のIOダイパーティションを基準にしたボトルネックは、帯域幅計算から明らかになる
- 隣接するIOダイと接する2つのedgeで、2.7TB/sのingress帯域幅を持つ
- そのIOダイに接続された2基のXCDは、4.2TB/sのInfinity Cache帯域幅を得られる
- L2 miss要求がダイ全体に均等にストライピングされると、3/4にあたる3.15TB/sがpeer dieから来る必要がある
- 3.15TB/sは2.7TB/sを上回るため、cross-die帯域幅がキャッシュ帯域幅を制限する
- すべてのダイが統合構成で最大Infinity Cache帯域幅を要求すると、対角側のダイ間転送は2-hopを必要とし、ingress帯域幅をさらに消費する
- MI300Xを複数のNUMA domainに分割すれば、合算のInfinity Cache帯域幅はより高くなる可能性がある
- 高いL2 hit rateはボトルネックの可能性を減らし、Infinity Cache hit rateが低い場合でも、MI300Xのdie-to-dieリンクはHBMトラフィックを処理するのに十分な帯域幅を提供する
XCD間のコヒーレンシーとL2の動作
- Infinity Cacheはコヒーレンシーを気にする必要はないが、L2キャッシュは別途処理が必要
- 一般的なGPUメモリアクセスはrelaxed coherency modelに従うが、プログラマはatomicsでスレッド間のorderingを強制できる
- AMD GPUのメモリアクセスはGLC(Global Level Coherent) bitで示せる
- 以前のAMD GPUではatomicsとcoherent accessがL2で処理されていた
- GLC bitが設定されたloadはL1をバイパスし、L2から最新データを取得する
- MI300Xでは最新のcachelineが別のXCDのL2にある可能性があるため、この方式だけでは不十分
- CDNA 3はRyzenのInfinity FabricのようにXCDとI/Oダイの接続部にCoherent Master(CM) を置き、各メモリコントローラの横にInfinity Cache sliceとともにCoherent Slave(CS)を配置する
- Ryzenのドキュメントから、Coherent Slaveにはprobe filterとatomic transaction処理用のハードウェアがあることが分かる
- MI300Xも同様のCS実装を持つとみられる
- coherent writeがCSに到達すると、GPUのどこで実行されるスレッドであってもcoherent readでそのwriteを観測できなければならない
- 単純な実装なら、CSはすべてのXCDのL2をprobeする必要がある
- probe filterはどのXCDがそのlineをキャッシュしているかを追跡し、不要なprobe trafficを避ける
- CDNA 3 whitepaperは、snoop filterが複数のXCD L2キャッシュをカバーできるだけの大きさを持つと述べている
- ただしXCD内部のCDNA 3は従来のGPUと同様に動作する
- 一般的なメモリwriteはCPUのようにpeer cacheのlineを自動でinvalidateしない
- コードはdirtyなL2 cache lineをwritebackし、peer L2 cacheのnon-local L2 lineをinvalidateするよう明示しなければならない
- 関連するLLVMドキュメントでは、GFX942 targetで
buffer_wbl2 sc1とbuffer_inv sc0 sc1を使う方法を説明している
L2とL1キャッシュの改善
- 各MI300X XCDはCompute Unitの近くに4MBのL2キャッシュを備える
- L2は16個のsliceで構成される
- 各256KB sliceはサイクル当たり128バイトの帯域幅を提供する
- 2.1GHz基準でXCD当たり4.3TB/sとなる
- MI300XはH100やMI250XよりL2 bandwidth-to-compute比が高い
- XCDごとにL2があるため、CDNA 3製品はXCDを増やすほどL2帯域幅も自然に増える
- 1つの大きなキャッシュに多数のCompute Unitを接続しつつ帯域幅を維持しなければならない問題を避けられる
- PVCはCompute Tileが増えるほどBase Tileの共有L2に対する帯域幅要求が大きくなる
- PVCの構造はL2がコヒーレンシーの単一ポイントであり、L1 missの受け皿でもあるため、キャッシュ設計の観点では単純
- MI300X L2ほど高い帯域幅は提供できない
- CDNA 3のL1も帯域幅重視で改善されている
- L1 throughputはサイクル当たり64バイトから128バイトへ増加
- L1容量も16KBから32KBへ増える
- より大きいキャッシュはhit rateを高め、平均メモリアクセス遅延を下げて実行ユニットの活用を改善できる
- L2以上からデータを取得するコストは電力を消費するため、hit rateの向上は電力効率にも有利になりうる
- Ponte VecchioはL1の面では依然として強い
- 各Xe Coreはサイクル当たり512バイトを提供する
- L1容量は512KB
- L1に収まるmemory-bound kernelはIntelアーキテクチャでうまく動作する可能性がある
- ただしCompute Tileレベルのmid-level cacheがないため、データがL1を超えると性能が急激に低下する可能性がある
スケジューリングと実行ユニット
- CDNA 3は、MI300Xを単一GPUとして見せるチップレット・キャッシュ構造に加え、Compute Unitアーキテクチャも継続的に改善し、CDNA 2のFP32活用の問題に対処している
- CDNA 2はFP64をネイティブに処理しつつ、packed executionによってdouble-rate FP32を提供していた
- コンパイラが2つのFP32値を隣接レジスタにpackし、同じ命令を実行する必要があった
- プログラマが明示的にvectorを使わないと、コンパイラがこれをうまく実現できない場合が多かった
- CDNA 3はより柔軟なデュアルイシュー機構でこの問題を回避する
- RDNA 3のVOPD/wave64方式より、GCNのmulti-issue機能拡張に近いように見える
- CU schedulerは毎cycle 4つのSIMDのうち1つを選び、実行準備ができたスレッドがあるか確認する
- 複数のスレッドが準備できていれば、GCNは最大5個を実行ユニットへ送ることができた
- CDNA 3のデュアルイシューは、コンパイラよりもプログラマが大きなdispatch sizeでthread-level parallelismを露出させたときに効果を発揮する可能性が高い
- SIMDがより多くのスレッドを実行中であれば、FP32命令を持つ2つのスレッドを同時に見つけられる可能性が高まる
- 少なくともSIMD当たりactive threadが2つ必要で、これによってフルFP32スループットを達成できる
- 実際にはmemory latencyやexecution latencyのため、より高いoccupancyが必要になる
- AMDはCDNA 3 SIMDが追跡できるスレッド数を8個から24個へ大幅に増やした
- vector register file容量の増加には触れられておらず、この容量はSIMDが同時に保持できるスレッド数を制限することが多い
- スレッド当たりのregister使用量が少ない単純なkernelで、multi-issue能力が最もよく機能する可能性がある
- デュアルイシューはregister file bandwidthも問題にしうる
- CDNA 2のpacked FP32は、64-bit値を渡す広いregister file portを利用するため追加のreadを必要としなかった
- 個別の命令は異なるregisterを参照し、より多くのreadを必要とする可能性がある
- AMDはsource cachingを世代ごとに改善し、1回のvector register readでより多くの下流vectorまたはmatrix operationを支えられるようにしたと述べている
- より大きなregister cacheでport conflictを緩和し、実行ユニットへデータを供給している可能性が高い
行列演算とAI性能
- 機械学習の普及によって行列積の重要性が増し、NvidiaはVoltaとTuringでtensor coreを追加してこの分野に大きく投資した
- AMD CDNAもmatrix multiplyをサポートしていたが、同時代のNvidiaアーキテクチャはFP16のような低精度データ型の行列スループットにより多く投資していた
- MI300Xは以前のCDNA世代と比べて、CU当たりのmatrix throughputを2倍に高めている
- MI300Xのチップレット設計は非常に多くのCUを可能にし、総スループットを引き上げる
- NvidiaはSM当たりのmatrix性能が高く、依然として強力な競争相手だが、CDNA 3はAMDの流れどおりvector FP64性能でNvidiaに強い圧力をかけつつ、単体でも高いAI性能を維持している
命令キャッシュの変化
- Compute Unitはデータメモリアクセスだけでなく、命令そのものもメモリから取得する必要がある
- GPUコードは伝統的に単純でコードサイズが小さく、instruction deliveryは比較的容易だった
- CDNA 2とRDNA GPUは32KBのinstruction cacheを継続して使用していたが、CDNA 3ではこれを64KBに拡大した
- associativityも4-wayから8-wayに増加した
- より大きく複雑なkernelでinstruction cache hit rateを高める
- AMDはCPUコードをGPUへ単純移植したケースを念頭に置いていたようだ
- 複雑なCPUコードはGPUでは負担になり得る
- GPUは長距離のinstruction prefetchingや正確なbranch predictionによってinstruction cache miss latencyを隠すのが難しい
- より大きなinstruction cacheは大きなkernelを収めるのに役立ち、高いassociativityはconflict missを減らす
- CDNA 3のinstruction cache instanceはCDNA 2と同様に2つのCompute Unitで共有される
- GPU kernelは通常、多数のCompute Unitを埋めるのに十分な大きさのwork sizeで実行されるため、instruction cacheの共有はSRAMを効率的に使う方式である
- より多くのCompute Unitが1つのcache instanceを共有すると、instruction bandwidth要件を満たしにくくなる可能性がある
MI300XとMI300Aの違い
- CDNA 3で最大の世代変化はメモリ階層であり、実際の中核的な改善もInfinity Cacheの追加にある
- MI250Xの主な問題は、1つのGPUというより同じパッケージを共有する2つのGPUに近かった点にある
- 2つのGCD間帯域幅は各方向200GB/sだった
- AMDは、この帯域幅ではMI250Xを1つのGPUとして見せるには不十分だと判断し、die-to-die帯域幅を大幅に拡大した
- MI300はEast-West全体帯域幅を各方向2.4TB/sへ引き上げ、MI250X比で12倍に増やした
- North-South全体帯域幅は各方向3.0TB/sとさらに高い
- この帯域幅増加により、MI300はMI250Xのような2つのアクセラレータではなく、1つの大規模な統合アクセラレータのように見えるようになった
- 単一のIOダイの総ingress bandwidth 4.0TB/sは、2つのXCDが使用可能な4.2TB/sとほぼ一致しており、現実的には大きな問題にならない
- ただし、単一のIOダイでは5.3TB/sの総メモリ帯域幅をすべて活用することはできない
- これはRyzen 7000で、1つのCCDがInfinity Fabricの制約によりDDR5帯域幅を完全に使い切れない状況に似ている
- MI300Xでは、すべてのダイが一緒に動作するときに帯域幅要求が最も高くなるが、この場合各ダイは約1.3TB/sを消費するため、cross-die link経由で3/4を持ってくることは問題にならない
- MI300Aは同じbase dieを再利用しつつ、6基のCDNA3 XCDと24個のZen 4 coreを組み合わせた「big iron」APUである
- CPUとGPUは同じメモリアドレス空間を共有できる
- CPUとGPUの一貫性を保つために外部バスでデータをコピーする必要がなくなる
1件のコメント
Hacker News のコメント
技術的には AMD のコンシューマ向けカードの計算性能は優秀。たとえば UE5 はグラフィックスパイプラインの代わりに計算で三角形メッシュをレンダリングする https://www.youtube.com/watch?v=TMorJX3Nj6U
しかも nVidia が計算性能やメモリ帯域幅よりもレイトレーシングと DLSS を優先したため、AMD のカードが同クラスの nVidia を上回る場合も多い
問題は、どの技術企業も PyTorch のような AI ライブラリに D3D や Vulkan バックエンドを追加しようとしないこと。nVidia は現状維持が都合いいのでやらず、Intel と AMD は公開 GPU API ではなく CUDA を自分たちの独自代替で置き換えようとしているのでやらない
ただし、これは雑な製品分離でも上位アーキテクチャの問題でもない。特化製品は汎用品より自分の領域でうまく機能する。計算もゲームも両方うまくこなすカードへの需要は小さく、そういう人はいても、どちらか一方しか気にしない人に比べれば少ない
GCN を RDNA と CDNA に分けた効果は即座に現れた。Radeon VII(GCN 5) と RX 5700 XT(RDNA 1) を比べると、ゲームでは互角で平均すると Radeon VII がわずかに上だが、RX 5700 XT は計算ベンチマークで大きく劣る。どちらも TSMC 7nm だが、RX 5700 XT はシェーダー数が少なく(2560 対 3840)、ダイも小さく(251 対 311 mm2)、消費電力も低い(225 対 300 W)ので、ゲーム効率がはるかに高いことを示している。低消費電力、低騒音、数百ドル安い価格のおかげで、ゲーマーにはずっと魅力的なカードだった
CDNA カードにはレンダー出力ユニットのようなゲームに必要な構成要素が欠けているように見える。そのため DirectX、OpenGL、Vulkan の公式サポートがない。これでゲームを動かした例は見たことがない。その代わり計算性能が非常に高いため、圧倒的な CUDA エコシステムがあるにもかかわらず、多くの企業が nVidia ではなくこのカードを買っている。2013 年には GCN ベースのスーパーコンピュータが 1 台トップ 100 に入っており、それが唯一の GCN ベースのトップ 100 システムだった。今ではエネルギー効率上位 10 台のスーパーコンピュータのうち 8 台がCDNA アクセラレータを使っており、総合 1 位の最速スーパーコンピュータも CDNA を使っている
https://www.tomshardware.com/news/amd-enables-rocm-and-pytor...
根本的にはハードウェア企業であり(Lisa Su の経歴が示す通り)、CUDA が決定打だという事実を早く受け入れられなかった。Phoronix で @Bridgman が開発者を引き留めようとする後退戦を続けていたのを覚えている。勝ち目のない戦いだった
ある程度は理解できる。80 年代/90 年代のハードウェア世代は、スタックの最上位にあるのはハードウェアだと本能的に考え、Su を含む AMD の経営陣も皆その出身だ
Kodura は、コンシューマ向けカードでも CUDA が動く点によって nVidia が AMD を圧倒していることを理解していた。だから Lisa Su に逆らって Radeon VII を押し進め、そのカードはつい最近まで何年もの間 ROCm がサポートする唯一のコンシューマ向けカードだった。彼はその後まもなく事実上解任され、優れたカードだった RVII もすぐに打ち切られた。その後 Wang が入り、コンシューマ向け/プロ向けの分離を固めた
今の AMD は必死に巻き戻そうとしているが、遅すぎた。競争相手になろうとしているところはいくつかあるが、実際に名前を挙げる価値があるのは AAPL と Metal くらいだ
AMD は機会を逃した
それでも、これは AMD カードの計算用途への採用には良かったとは思えない。CUDA の優れている点は、CUDA コードを開発するのに特殊なアクセラレータカードが不要なことだ
彼らが自分の金や研究費で、一般消費者と同じ価格を払って GPU を買わなければならなかったなら、状況は違っていたかもしれない
個人的には、NVidia が学界や大学の研究環境に食い込むやり方は非常に非倫理的だと思う
その後も待ち続け、自分たちが作った製品の市場が「来る」と信じて何度も会社を賭けてきた
ここ数年でそれが実際に起こり、株価にも反映された。ほかのプレイヤーは基本的に 10 年遅れており、今の過熱した空気と AI/ML ワークフローの大衆化を見ると、誰かが追いつくのはほぼ不可能に見える
一方で CUDA コードは、新しい Nvidia カード世代が出ても動き続けた
大半は Exxact や Supermicro のような企業から、A6000 以上をコンシューマー向け価格で買っている。
V100 の時代、つまり DGX-1 システム以降、研究者が無料の GPU を受け取るのは一度も見たことがない気がする
CPU とは異なり、GPU はこれを直接相殺しようとはしない。より高いレイテンシを受け入れる代わりに、CPU と比べてはるかに広く、あるいは大胆に並列化し、無数の並列擬似スレッドが レイテンシ隠蔽 効果を提供する。
この効果は、たとえば GPU コード最適化の発表でも見られる。
https://www.olcf.ornl.gov/wp-content/uploads/2019/12/03-CUDA...
スライド 11 から出てくるアニメーションがその例である
つまり多くの処理を純粋にレジスタと LDS でこなせ、グローバルメモリアクセスは、ほぼすべてがグローバルメモリ上にありアーキテクチャレジスタが 16 個前後しかない CPU よりもはるかに少ない。
それでもグローバルメモリは問題である。レイテンシだけでなく 帯域幅 も問題だからだ。そこで RDNA2 と Ada は大量の最終段キャッシュを追加した。レイテンシをよりうまく隠すためでもあるが、主目的は 帯域幅増幅器 としての役割である
Very long instruction word(VLIW) は、命令レベル並列性（ILP）を活用するよう設計された命令セットアーキテクチャを指す。一般的な中央処理装置（CPU）は、おおむねプログラムが順番に実行する命令だけを指定するが、VLIW プロセッサでは、並列に実行する命令をプログラムが明示的に指定できる。この設計は、他方式に内在する複雑さを避けつつ、より高い性能を得ることを目的としている。
プロセッサ性能を高める伝統的な方法には、命令を下位段階に分けて一部を同時実行するパイプライン化、個々の命令をプロセッサの別の部分で独立して実行できるよう送るスーパースカラアーキテクチャ、さらにはプログラムとは異なる順序で命令を実行するアウトオブオーダー実行がある。こうした方式は、プロセッサが内部ですべての判断を下さなければならないため、ハードウェアを複雑にする。
https://en.wikipedia.org/wiki/Very_long_instruction_word
うまくはいかなかった。だから Itanic と呼ばれた。
前提は、コンパイラが依存関係を十分に静的に把握し、複数の逐次実行経路や一部の分岐実行経路を同じ命令の中に入れられるというものだった。しかし実際にはコンパイラにそれはできないことが明らかになり、その結果、プロセッサが逐次命令ストリームから依存関係と並列化可能な命令を動的に見つけ出すようになった。
これは多くの作業、多くのチップ資源、多くのエネルギーを必要とする。そしてある時点まではうまく機能するが、その先では限界効用逓減に突き当たる。今の私たちはまさにその地点にいるように見える
これは命令を送る言語ではなく、処理方式そのものを指す。
そして VLIW4 や VLIW5 のような用語は特定の実装を指すことも覚えておくとよい。
https://en.wikipedia.org/wiki/Single_instruction,_multiple_d...
0: https://en.m.wikipedia.org/wiki/Amazon_Elastic_Compute_Cloud
1: https://trends.google.com/trends/explore?date=all&q=Compute&...