AMDに関するウワサ 2題
Zen3+ "Warhol"
AMD Ryzen 6000 'Warhol Zen 3+' CPUs Reportedly Cancelled - WCCF Tech
一部で噂されていたZen3+ = Warholがキャンセルされたのだという。
そもそも、AMD公式はZen3+について一切言及しておらず、そのような計画が存在したかすら疑わしいが、ウワサによるとZen3に改良が加えられた上でTSMC N6で製造されるとされていた。国内大手メディアでは例えばASCIIで大原氏が言及している。
筆者は個人的にはWarholの存在自体がデマではないか、あるいは誇張・ミスリードが含まれていたのではと考えている。
コードネームWarholの真偽はともかく、恐らく今年後半にZen3のリフレッシュ版は登場することだろう。ただし、それはWarholとしてウワサされたような小改良版ではなく、Zen2の「XT」サフィックス付モデルのようなリフレッシュ版かもしれない。そもそも、2021年は新CPUモデルの無い空白の期間となるのでビジネス的な理由で年末商戦を目処にZen3のリフレッシュ版を出す必要があるだろうと推測できる。さらに、（大原氏も指摘されている通り）TSMCの主張通りN7とN6に互換性がある（参考）ならTSMC N7で製造されているZen3世代単体CPU=VermeerをN6に移すなりした程度の変更が行われる可能性はあり、この場合は動作周波数が向上するか消費電力が下がる可能性がある（※ただしIPCは向上しない）。
しかし、Warholでウワサされたのはその程度の改良ではなく、一説によると平均9％・最大～12％程度IPCが向上という話であった（IPCがそれだけ伸びるということは、論理設計レベルでの変更を示唆している）。昨今のAMDはモジュラー設計とアジャイル的でインクリメンタルな開発手法を導入しているようで、Zen3にZen4で導入予定の新機構の一部を設計レベルで導入したZen3+（仮称）を作り出すことは不可能では無かろう。実際、例えばZen2で導入されたTAGE分岐予測はZen3で導入予定だったものを前倒ししたりしている。ただし、それを物理実装し・マスクを作成し・検査するか？と言えば疑問に思う。もし今年後半に新CPUが出るなら、その昨年後半にはテープアウトして検査している必要がある。あるいは、本当にAMDがそのようなものを計画していたのだとすれば、（2018年のZen+と同様に）過去の発表でZen3+などが登場していたのではないか。
ただ、このタイミングでキャンセルの話がでてきたのは興味深い。というのも、TSMCの7nm/5nmの予約が2022年末まで・3nmは2024年末まで予約が埋まっていることが報じられたからだ。
言い換えると、AMD（やNVIDIAやAppleやQualcomm）が来年末までにTSMCで製造するウェハーの数は確定してしまっており、あとは各社の社内での調整が必要になる。例えば、Zen3リフレッシュ版としてVermeerをTSMC N7からN6に移すことを検討あるいは計画していたが、Zen3世代APU=Rembrandtや一部RadeonのモデルでN6が必要なのでTSMC N6版のZen3単体CPUは無くなった、ということかもしれない。
"Zen 5"世代のAPU"Strix Point"はbig.LITTLE構成を採用するのか
AMD Zen 5 "Strix Point" Processors Rumored To Feature big.LITTLE Core Design - TechPowerUp
AMDがbig.LITTLE相当の実装することは案外難しく個人的に信憑性は薄いと考えるが…仮にAMD内で構想があるとしたら、既に設計が進んでいることだろう。
信憑性を疑問視する理由はAVX-512である。
ArmやIntelの実装でもそうだが、bigコアとLITTLEコアは命令セットを互換にする必要があるためだ。Armの場合はbig.LITTLE導入時にCortex-A7/A15とLITTLEコアとbigコアで新コアを出したし、Intel Lakefieldの場合はbigコア=Sunny Coveの機能（AVX/AVX-2/AVX-512）を無効化しLITTLEコア=Tremontに合わせることによって対応している（参考）。これは、現在のbig.LITTLEのソフトウェア側の実装がOSのタスクスケジューラーから見て、負荷に応じてbigコア・LITTLEコアを使い分けているのであって命令セットによって使い分けているわけではないからだ。
例えばあるタスク（例：Google Chrome）をCore0で動作させていたところCore0-3は未対応でCore4-7で対応している命令セットが出てきたらどうするのか？という話で、不可能ではないがなかなか面倒なことになる。何より、高コストなコンテキストスイッチが発生するなら、省電力機能の実装で負荷が増えてしまうという本末転倒なことになりかねない。
ウワサの信憑性を検証しても仕方がないので、仮にAMDがbig.LITTLE相当の実装を実現し、Zen系コアをbigコアとすると仮定した場合に疑問となるのは、LITTLEコアはどうなるのか？ということだろう。
多くの人が真っ先に思いつきそうなのはBobcat/Jaguarなどのいわゆる猫系コアであるが、筆者は2点の理由で否定的である。まず、当時の猫系コアを開発していたチームは既にAMDにいない（Samsungに移籍後に解散した）こと、次に命令セットの問題である。上述の通り猫系コアの命令セットをZen5に合わせる必要がでてくるが、AMDはZen4でAVX-512の実装がウワサされているからLITTLEコアもAVX-512のサポートを追加する必要が出てくる。JaguarはAVXをサポートしていたが物理的には128-bit SIMDのままだった（参考）。この場合物理レジスターの拡張やロード/ストア帯域を具体的には4倍以上に引き上げる大改造が必要になる。これらを総合的に考えた場合、あまり現実的とは思えない。
ここからは筆者の想像であるが、Zen系コアを派生させるのではないか。
同一系統の昔のコアから派生させるのはAMDが最初ではない。大原氏のITMediaの記事によるとAppleのbig.LITTLE実装のLITTLEコアはA6で採用されたApple初ArmコアSwiftの派生なのだという（いろいろ調べてみたが、大原氏の記事以外でソースが見当たらないため真偽は不明）。
正確な数字が公表されていないため概算となるが、トランジスター数はZen→Zen2でコア周りの概ね＋30％増加・Zen2→Zen3で＋10％ほど増加しているようで、TSMC N3で製造されるZen 5ではトランジスター数はZenの2.5倍ほどになっていても不思議ではないから（※製造プロセスが進む毎に+30％増える想定）、LITTLEコアを初代Zenと同等に抑えれば実現は可能そうに思える。
# もっとも、ArmもIntelもLITTLEコアの実装コストはbigコアの～1/4程度のようだからLITTLEコアとしてはやや大きめではある
MicrosoftはHyper-VにArm用の改良を加えている
Microsoft Prepping Linux For Running As 64-bit ARM Hyper-V Guest - Phoronix
Microsoft、Hyper-VとAzureでARM64版Linuxサポート改善の動き - マイナビ
記事を読む前の事前知識として、MicrosoftはAzureにて市販されているものとは異なるバージョンのHyper-V=Azure Hypervisorを稼働させている。言い換えると、Azure Hypervisorで入った変更が市販されているWindows Server添付のHypre-Vに反映されるとは限らない。
昨年12月頃、MicrosoftがArmベースのサーバープロセッサーを開発中と報じられているから、それが真実ならMicrosoftがAzure HypervisorでArmをサポートすることは想像に難くない。しかし、Arm版Windows Serverが市販されたりAzureのインスタンスで提供されるか否かは別問題だと想像する。
そもそも、AWSの場合も2015年にAnnapurnaLabsを買収してから2018年にAWS Gravitonを発表するまでの間にElastic Network AdapterやNitro Security Chipなど多方面でAnnapurnaLabs製Arm SoCを開発し採用していた。恐らくS3やELBなどもAnnapurnaLabs製Arm SoCを採用していたことだろう。L2スイッチやストレージなど一部のネットワークアプライアンスはCPU使用率が高くなることは稀でArmに置き換えることで消費電力を削減できる可能性は高いからだ。
AWS・Azure・GCPクラスのハイパースケーラーであれば低消費電力なカスタムプロセッサーを内部利用向けに内製することは何ら驚くことではない。ただ、インスタンスとして外部に提供するとなると各種サポートが関わってくるため簡単な道のりではないように思う（AWSがGravitonインスタンスを用意できたのはLinuxで使う前提で、Amazon LinuxもベースのRed Hat Enterprise LinuxがArm対応済だったからだろう）。
※コメント投稿者のブログIDはブログ作成者のみに通知されます