ALH84001

私的コラム&雑記(&メモ)

最近の気になった話題(2021年第21週)

2021-05-29 | 興味深かった話題

ArmがArmv9-AアーキテクチャーのCortex-X2・Cortex-A710・Cortex-A510を発表

Arm Launches Its New Flagship Performance Armv9 Core: Cortex-X2 - WikiChip
Arm Unveils Next-Gen Armv9 Big Core: Cortex-A710 - WikiChip
Arm Unveils Next-Gen Armv9 Little Core: Cortex-A510 - WikiChip

 今回の発表と前回のCortex-X1・Cortex-A78発表時との最大の違いはArmv9-A対応だろう。
 現在のbig.LITTLEでは負荷の大小でコアへのスケジューリングを調整するため命令セットは共通である必要があるためArmv9-A・big.LITTLE対応のクラスターを構成するためにCortex-X2・A710・A510を同時に発表したと考えられる。これはArmv8-A発表後のCortex-A57・A53が既存のArmv7-AのCortex-A15・A7を置き換えたのに似ている。

 そのためか、Cortex-X1→X2もCortex-A78→A710も性能向上幅は小さく抑えられ、ほぼ命令セットを置き換えただけで、次のパフォーマンス向上は次世代コアに持ち越されたように見える。
 Armには現存の開発チームが米国(2チーム)・英国・フランス・ノルウェー・台湾の6チームが存在するが、ノルウェーはGPU・台湾はCortex-M系となっており、Cortex-X2・A710は米国Austinのチーム・Cortex-A510は英国Cambridgeのチームによるものである。他に高性能コアを手掛けるのは仏Sophia-Antipolisのチームで、AnandTechによると次期高性能コアはSophia-Antipolisチームのものという。

 高性能コア=Cortex-X系が定着したことでCortex-A7x/A7xx系は高性能コアというよりも効率重視に変化してきているように見える。
 big.LITTLEでbig=高性能コア・LITTLE=高効率コアということで見逃されがちだが、高性能コア=Cortex-A70系でもCortex-A73までとCortex-A75/A76以降とでは方向性が違い、A710でも少し方向性が変わってCortex-A73までの方向性に近くなっている。
 もともと、Cortex-A70系は高性能コアとはいいつつも高性能スマートフォンで実装コストや電力効率が重視されておりIPCの向上には制限が付いていた。そのため、例えばSamsungのExynos MコアやNVIDIAのDenver/Carmelコアのような俗に"Super"と分類される実装が存在していた。大まかな実装コスト(トランジスターコストあるいはダイサイズ)でいうとSuper:big:LITTLE=8:4:1程度である。それがCortex-A75からは明確にIPC向上へ方向転換した。Armの説明ではCortex-A75→A76→A77でそれぞれ+35%・+20%のIPC向上となっている。これらのコアでは半導体プロセスの進化(微細化・トランジスターの高性能化)により動作周波数も向上するから実際の性能向上幅はより大きくなる(参考)。
 それがCortex-A78・A710では再び効率が重視され性能向上に制限がかかるようになった。恐らくCortex-X系のIPCをどんどん引き上げるシリーズが登場したためだろう。Cortex-A77→A78では動作周波数向上分も合わせて+20%、Cortex-A78→A710ではIPCが+10%と説明されており、Cortex-A710では、TLBの強化やSVE/SVE2対応など高性能化が進む一方で、MOP Cache帯域と命令発行帯域が減少(6 MOPs/cycle→5 MOPs/cycle)している。

 今回発表された中で個人的に興味深く感じたのはCortex-A510だ。基本的なスペックはCortex-A55に似ているがAdvanced SIMD/SVE/SVE2ユニットが2コアで共有される形へと変更になった。通常のスマートフォン/PC用途では整数のスカラー演算の出現頻度が高いから浮動小数点/SIMD演算ユニットが共有とされるケースはCortex-A510が初めてではなく、AMDのBulldozer~ExcavatorやSun MicrosystemsのNiagaraでも同様に2コアで共有される形だった。
 ただ、個人的に気になるのは64-bit x2または128-bit x2となっている点である。SVE/SVE2の場合は論理的には最大2048-bit幅のSIMDとなる。Cortex-X2ではSIMDユニット128-bit x4(2サイクル)・Cortex-A710ではSIMDユニットが128-bit x2(4サイクル)だが、Cortex-A510のSIMDユニットが64-bit x2の場合の遅延がどうなるのか気になるところである(というか、それ以前にSVEは128-bit~2048-bitでの実装だったはずで、SIMDユニットが64-bit x2の場合SVEには対応するのだろうか?)。

 Cortex-A510ではIn-order実行ながらCortex-A55の2-wideから3-wideへと変更になった。現時点でCortex-A510の内部構成は公開されていないが、想像するにIn-order実行コアとしてはかなり重厚な構成で次世代LITTLEコアはOut-of-Order実行コアになると予想する。
 Cortex-A55が2-wideとは言っても実行ポートが2ポートというような意味ではなく、Armの公開した図を信じるのであればALU・Integer・FPU/SIMDが各2ユニット、Load・Storeが各1ユニットで必ず2命令発行可能だったようだ。複数の演算ユニットが実行ポートを共用しているのか演算ユニットごとに実行ポートがあるのかArmの図からは読み取れないが、命令デコード数と演算ユニット数だけで見れば2015年のハイエンドコアCortex-A72(3命令デコード・3 Integer/ALU・1 Branch・2 SIMD/NEON・2 Load/Store)相当で、In-order構成の方が不思議なほど重厚な構成である。加えて、シングルスレッド・In-orderだと同時発行できる命令数にも限界があるから、Cortex-A510後継の次世代LITTLEコアはOut-of-Order実行コアになると予想する。

 ところで、2023年には32-bitのA32命令サポートが打ち切られるそうだ。もっとも、32-bitが必要と考えられる純粋な組込コアのCortex-R系/Cortex-M系は32-bitサポートが継続されるだろうから、問題無さそうに思える。

米エネルギー省バークレー国立研究所NERSC「Perlmutter」

Berkeley Lab Debuts Perlmutter, World’s Fastest AI Supercomputer - HPC Wire
4EFLOPSのAI性能を発揮するNVIDIA A100搭載スパコン「Perlmutter」- PC Watch

 米エネルギー省のHPCが2020~2023年に続々と登場するが、その第1弾が2020年末から構築の始まっていたPerlmutterである。~2023年に登場する米エネルギー省の4台のHPCとしては最後のPre-Exascale HPCとなる。以下は2023年までに導入される4台に、比較のため2018年に導入されたSummit/Sierraを加えた表である。
※もっとも、Summit/Sierraなどは途中で公開されたスペックがそのままだったり、導入後にアップグレードしたりで資料によって数字が違い計算が合わない。例えばORNL SummitなどはORNLサイトには「たった4,608ノード」と記載があるが、Top500の記載(SMT8の論理コアを含め2,414,592コア)という記載から逆算すると12,576ノードになる

Site System Year Contractor Base Nodes CPU Cores Accelerators Memory Interconnect Bandwidth Topology HP LINPACK
DOE LLNL ATS-4 El Capitan 2023 Cray Cray Shasta   AMD Epyc   AMD Instinct   Cray Slingshot     > 1.5 Exa Flops
DOE ORNL OLCF-5 Frontier 2022 Cray/AMD Cray Shasta   AMD Epyc   AMD Instinct   Cray Slingshot     1.5 Exa Flops
DOE Argonne   Aurora (A21) 2021 Intel/Cray Cray Shasta   Intel Xeon   Intel Xe   Cray Slingshot     1 Exa Flops
DOE LBNL NERSC-9 Perlmutter 2021 Cray/NVIDIA/AMD Cray Shasta   AMD Epyc   NVIDIA A100
CPU-GPU Nodes
  Cray Slingshot 200 Gbps Dragonfly Pre-Exascale
DOE ORNL OLCF-4 Summit 2018 IBM/NVIDIA IBM PS AC922 12,576 IBM POWER 9
25,152 CPUs
301,824 NVIDIA Volta V100
75,456 GPUs
2,801,664 GB Dual-rail EDR InfiniBand 100 Gbps Fat-tree 148,600.0 TFLOPS
DOE LLNL ATS-2 Sierra 2018 IBM/NVIDIA IBM PS AC922 7,920 IBM POWER 9
15,840 CPUs
190,080 NVIDIA Volta V100 1,382,400 GB Dual-rail EDR InfiniBand 100 Gbps Fat-tree 94,640.0 TFLOPS

 PerlmutterはCPU-GPUノードとCPU Onlyノードの二種類のノードで構成される点がユニークで、今回稼働開始したのはCPU-GPUノード(1,536 Nodes = 128 Nodes/Cabinet x 12 Cabinets)のみ、残りのCPU Only Node 12 Cabinetsは今年半ばに搬入予定である。

 詳細はPerlmutterのスペックシートに詳しいが、1ノードあたりAMD "Zen 3" Epyc 7763 2基に256 GBのメモリーとNVIDIA "Ampere" A100 GPU 4基が接続される構成となっており、各ノードはCray Slingshotで接続される。1536ノードで計196,608CPUコア・393,216 GBのメモリー・6,159 GPUで構成される(※1,536 Nodesなら6,144 GPUのはずである)。
 CPU Onlyノードが導入されても約3,000ノードで規模的にはORNL「Summit」には及ばず、科学演算ではFP32/FP64演算性能も理研「富岳」やORNL「Summit」には及ばないが、A100を搭載していることもありMLワークロード/Tensor演算に強く、PC Watchにある「FP16/FP32混合精度演算によるAI処理において約4EFLOPS(エクサフロップス)を発揮でき、FP64でも約120PFLOPSの演算性能」とはいずれもA100に内蔵されているTensorCoreによる演算性能である。通常の科学演算ではFP32で約120 PFLOPS・FP64で約60 PFLOPSとなる。PC Watchの記事では「現時点でTOP500の5位に相当する」とあるが、TOP500の5位(63.46 PFLOPS)・6位(61.44 PFLOPS)が理論値ではなく実測値であることを考えると5位が妥当なのかよく分からない。

Comment

最近の気になった話題(2021年第20週)

2021-05-22 | 興味深かった話題

富岳HPCのコデザイン

富岳スパコンはどのように考えて開発されたのか?- マイナビ

 リンク先の連載記事は「富岳」開発に関する理研R-CCSのアーキテクチャ開発チームのチームリーダの佐藤三久氏のCOOL Chips 24での発表内容を基にHisa Ando氏が解説を付けたものであるが、全9回に渡る長期連載で読み応えがある。非常に興味深く読ませて頂いた。

 理研/富士通の開発した「富岳」は、「ポスト京」と呼ばれていた時代も含めれば随分と沢山の記事があり、マイナビに掲載されている名称決定以降の記事だけでも30件を超えるが、筆者が読んだ限りでは、今回の連載でのポイントはコデザインではないかと思う。実際、第3~4回はどのようにコデザインが行われたか概要、第5~6回はハードウェアについて、第7~8回は第3~6回の内容を踏まえてコデザインのポイントと得られた結果を解説しているように読める。
 富岳運用開始前はハードウェア特にマイクロプロセッサーに焦点をあてた記事、運用開始前後ではシステム全体のアーキテクチャー、運用開始後は性能や得られた成果に関する記事が多かったように思われるが、今回はコデザインを取り上げることで過去に発表された内容を踏まえつつ、ハードウェアからアプリケーションまでの統合するような内容となっている。第5~6回の内容自体は過去のハードウェアの記事と重複する部分があるが、今回はコデザインという観点から見ているので類似の内容でも見え方は異なるように思う。

 記事中で解説されている内容そのものに異論・反論を唱える気は無いが、この種の内容に馴染みのない読者は注意が必要だと思う。それはコデザインは乱暴に言ってしまえば、ワークロードに最適化するようにハードウェア・ソフトウェアを協調的に開発するという事になるのだろうが、例えば第7回で比較対象として挙げられているIntel "Skylake-SP" Xeon ScalableやMarvell "Vulcan" Thunder X2への適用は限定的に考える必要があるからだ。

 なぜなら、Intel Xeon ScalableシリーズもMarvell Thunder Xシリーズも汎用的なサーバー用プロセッサーであってHPC専用プロセッサーではないし、Intel "Skylake"コアに至ってはTDP 15wのモバイルからTDP 200w超のサーバーまでを単一のアーキテクチャーでカバーしているからである。
 HPCではユーザーがアプリケーションをHPCシステム毎に再構築する/できるケースが多いと考えられるが(※8年ほど前の古い記事だがNVIDIA CEOのJen-Hsun Huang氏もNVIDIAがx86ではなくARM CPUに取り組む理由について「HPCの世界ではアプリケーションは世代毎に再構築されるので、どのようなCPUだろうが、GPUだろうが大きな問題にはならない」と語っている)、PC/サーバー用プロセッサーでは、どのコンパイラーの、どのオプションでコンパイラーしたソフトウェアであっても高速に動作する必要がある。

 例えば第7回のL2キャッシュについての解説部分を考えると、解説にある通りコデザインが前提であれば大容量キャッシュの統合を諦め、そのハードウェア=A64FXに最適化したソフトウェアを開発できるかもしれないが、そのような開発思想はIntel Xeonシリーズでは採用できないだろう。
 Intel "Skylake-SP" Xeonでは、各コア1MBのL2キャッシュとコアあたり1.375MB(最大28コアで38.5MB)もの共有のLLキャッシュを搭載しているほかSMTが実装されており、"Skylake"コアの実行パイプライン構成に最適化されていないコードでも実行ユニットを遊ばせることなく処理を続けることができるが、その代償としてL2・LLキャッシュにコアの約1/4・SMTの実装にコアの5%以上もの膨大なリソースを費やしている。

 乱暴に言えば、もしかすると富士通A64FXと同様のコデザインの結果、理論上ではIntel "Skylake-SP" XeonでもL2・LLキャッシュを廃止することで同じダイサイズで28コア→38コアにコアを増量でき特定用途での演算性能が大きく向上させることが可能かもしれないが、Intelは汎用的な処理性能を選択することにより"Skylake"コアを15Wのモバイルから200W超のサーバーまでを単一のアーキテクチャーでカバーできるというトレードオフが成立している。
 その結果として、HPCベンダーは大量生産されている汎用のIntel Xeonプロセッサーを採用してHPCを構築できる。コストの計算の仕方が米国と日本とで異なるため単純比較はできないとはいえ、米エネルギー省のフラッグシップHPCの場合2015年のOLCF-4/Summitが約350億円($325 million)・今年末~来年初頭に登場予定のAuroraが約540億円($500 million)に対し、理研の富岳のプログラムコストは約1,300億円となっている。 

 その結果得られた性能については第7~9回に数字が登場し、それら自体は確かに見事なものだが、そもそも米国などはCPU + GPGPU(アクセラレーター)による演算が主流なので、第7回に登場するような富士通A64FXとIntel "Skylake-SP" Xeon・Marvell Thunder X2との比較がフェアなのかよく判らない。一部のベンチマーク結果では特にThunder X2が大敗しているが、そもそもThunder X2は128-bit SIMDエンジンのARMv8-A Advanced SIMDしか搭載しておらずHPC用途で使うのであればNVIDIAかAMDのGPUと組み合こととなるだろうからCPU単体で比較対象として妥当なのか疑問である。
 もちろん、コデザイン手法を含む富岳の開発で得られた知見は日本のHPC業界・理研RCC・富士通にとって学術的にも産業的にも有益な経験だったろうし、そのための投資という側面もあろうから、そもそもIT最強国家=米国と米国企業製品と比較することは野暮かもしれないが…。

 ところで、個人的に今回の連載で衝撃的だったのは、異なるCMG(Core-Memory Group)間ではメモリーが独立でデータのやり取りの必要がある場合は同じノード内でもMPIで通信する必要があるという点である。CMGには演算用の12コアとは別に1コアのアシスタントコアがあるが、その謎が解けた気がする。
 HPCに限らず、I/Oに代表されるようなCPU時間に比して非常に長い遅延が発生する処理では、演算を妨げないように専用にCPUコアを割り当てるケースがよくある。マルチコアのネットワークプロセッサーなどでは1コアを専用に割り当てたりする。これは富士通に限った話では無くIBM BlueGene/Qでも17コア中の1コアはI/O用である。
 しかし、もしA64FXの4個のクラスター(CMG)がAMD "Zen"世代 EpycのZeppelin(2 CCX + UMCを集積したダイ)のようにフラットにメモリーにアクセスできるのであればアシスタントコアは各CMGに1コアも必要なかったかもしれない。各CMGに1コア・A64FX 1ソケット=1ノードで4コアも必要なのは、そもそもメモリーがCMG内でしか共有されておらず、他のCMGのメモリーに格納されているデータにアクセスするにはMPI(同一ノード内)なりOpenMP(他のノード)なりで当該のCMGで代わりにメモリーにアクセスしてくれるコアが必要だからだろう。

 富岳の設計思想として、1単位のジョブが原則として1コアまたは1 CMGで完結し、他のCMGとの通信が多発しない前提であればそれで問題ないのだろうが、比較対象として挙げられているIntel XeonやMarvell Thunder Xが一般的に使われるサーバー用途ではパフォーマンスが発揮されないことだろう。
 ところで、理研/富士通は先代「京」では富士通SPARC64VIIIfxを採用したが、これは富士通のUNIXサーバー用SPARC64シリーズの派生で、基本アーキテクチャーは共通で例えばSPARC64VIIはUNIXサーバー用・SPARC64IXfxはHPC用といったように作り分けられている。富士通がA64FXで同様の製品展開をするのか不明であるが、A64FXをサーバー用に転用するには大幅なアーキテクチャー変更が必要になりそうである。

 本稿はツッコミや批判のような内容となってしまったが、マイナビのHisa Ando氏の記事は読み応えがあるし、HPC用途に限定すれば納得のいくものである。
 ただ、やはりHPC用限定でマイクロプロセッサーからシステムまで作っているのは世界中で日本と中国ぐらいなので、非常に小さいHPCマーケットでしか使えない専用ハードウェアというのは先行きに不安を感じずにはいられない。

Google TPUv4

Google、1エクサフロップを超える性能を持つ「TPU v4」発表、Google史上最高性能のシステム - IT Media

 以前Google TPUを開発していたメンバーがGroqを設立したので、個人的にGoogleが自社開発TPUを続けるのか疑問に思っていたが、TPUv4が発表された。もっとも発表されただけで詳細は不明である。

 個人的に気になるのは「1エクサフロップを超えるGoogle史上最高性能」というくだりである。マーケティング用のあまり意味のない説明ではないかと思う。
 Google TPUv4の詳細は不明なのでこの指摘が妥当なのか不明だが、Google TPUを含むNeural Processing Unit=NPUにはSIMD演算ユニットやMatrix演算ユニットのクラスターで構成されているが、基本的に積和算のようなNeural Network処理に必要なオペレーションにしか対応していないので汎用的でないことが多い。恐らくIntel CPUに搭載されるAVXユニットやNVIDIA GPUに搭載されるCUDAコアとは異なり、除算などは演算できないのではと思われる(※注:除算は実装が非常に重いことで有名。NPUを実装するならば除算を省く代わりに、より多くの演算ユニットを積む方が有益である)。
 恐らく「1エクサフロップを超える」と言っても「※ただしMLアプリケーションに限る」という注釈が付くはずで、例えば米エネルギー省が導入を計画している1エクサフロップ超のHPC(通称:エクサスケールHPC)とは意味が異なるのではと思う。

Comment

最近の気になった話題(2021年第19週)

2021-05-15 | 興味深かった話題

IBMが2nmプロセスを開発

IBM、世界初となる2nmプロセス。バッテリ寿命4倍に - PC Watch
IBMが開発した2ナノメートルの半導体技術が、米国にもたらす大きな価値 - WIRED.jp
IBM Unveils World’s First 2 nm Chip - EE Times

 先週の記事だが、Wiredの記事があまりにミスリードを誘う記事に読めたのでコメントしておこうと思う。

 IBMがリリース中で述べている、ナノシート技術を利用することで高度な半導体スケーリングを可能にしたという新技術は称賛されるべきだが、それ以上でも以下でも無い内容である。
 研究開発レベルでは実用レベルの製品をスペック的に遥かに上回る試作品を作れる場合がある。それ自体は研究開発・将来の実用化までの一歩ということで重要なステップだが、それが製品化されるとは限らない。製品化されるには歩留まり(良品率)や量産方式の確立やコストなど様々な要因が関わってくるため当然である。
 Wired誌の記事はあたかもIBMの技術で数年後には米国企業が2nmプロセスで製品を製造可能になると言わんばかりだが、そんな単純な話では無い(※注:1990年代のWired誌は他誌とは異なるテーマを扱った優良な記事が多数あったが…決して技術的に優れたライターが記事を書いている雑誌ではない)。実際、IBMは2017年に5nmプロセスのテストチップを開発しているが米国で5nmプロセスを製品を大量生産している企業は2021年5月現在で一社も存在しない。

 もっとも、個人的に興味深いのはこの試作品の製造が何処で行われたかである。
 EETimesの記事によるとIBMのNew York州AlbanyにあるR&Dセンターで製造されたそうだが、Hisa Ando氏は300mmウエファなのでPowerやZを作っているファブでの製造と推測されている。しかし、POWER 9やz15を14nmプロセスで製造を担当しているGlobalFoundriesは既に先端プロセスから撤退済のため筆者としては懐疑的である。

 筆者が今回関与している、あるいは今後関与すると考えているのはIntelである。Intelは3月にIntel Foundry Servicesを発表したが、その際にIBMとプロセスルールやパッケージ技術の開発で協力するとしていた。
 そもそも、2014-15年にIBMが自社ファブをGlobalFoundriesに売却した際には10年間のIBMサーバープロセッサーの排他的な製造権・IBMの持つ数千の特許や知的財産・将来のIBMの研究成果を利用できる権利が売却内容に含まれていた。言い換えればGlobalFoundriesが2014年から10年間のIBM POWER・Z CPUを製造するのでIBMが半導体技術開発を支援することになっていたわけだ。ところが、現実にはGlobalFoundriesは2018年に先端プロセス開発を無期限で凍結してしまった。製造ファブを持たないIBMが先端半導体技術の研究開発を続行しており、IntelとIBMとプロセスルールやパッケージ技術の開発で協力するということは、IBMが恐らくIntelに技術を提供しIntel工場で将来のPOWER・Z CPUを製造することを示唆していると思われる。

GPD WIN Max 2021

GPD 初のRyzen 7 4800U採用ゲーミングUMPC「WIN Max 2021」- PC Watch

 CPUをIntel "Tiger Lake" Core-i7 Core i7-1165G7/1185G7またはAMD "Renoir" Ryzen 7 4800Uに換装したGPD WIN Max 2021が登場するのだという。

 Intel CPUとしてはハズレ世代と言っても過言ではない"Ice Lake"搭載版WIN Max (2020)ユーザーとしては複雑な心境ではあるが、PC Watchの記事によると、既存のWIN Maxユーザーはクラウドファンディングを介しマザーボードだけを入手してアップグレードできるようにするのだそうだ。配慮は素晴らしいところだが、当然ながら自作PCと違い余剰部品を使ってもう一台組めるわけでもなければ、Ice Lake→Tiger LakeにしろIce Lake→Renoirにしろ性能向上幅は限定的なので悩ましいところではある。
 もし安価にアップグレード可能なら交換したいところだが、メインボードには$400前後するCPU(1165G7, 1185G7, 4700U)・LPDDR4Xメモリー・Ethernet(Wired・Wi-Fi)がハンダ付で搭載されていることを考えれば最低でも$500以上すると見るべきだろう。筆者はWIN Max (2020)をIndieGoGoクラウドファンディングで入手したが$779だった。仮にWIN Max 2021が同価格なら買い替えた方がコストパフォーマンスは良いかもしれない(が、CPUが+$100前後するため恐らく$900前後になると思う)。

 記事によるとGPDはゲーミング用にはIntel Core i7-1165G7/1185G7、クリエイティブ用にはAMD Ryzen 7 4800Uを推奨しているようだが、確かにベンチマークなどを見るとそういう傾向は掴むことができる。ちなみに、もし筆者がWIN Max 2021を入手するとしたらRyzen 7版と思う。

Comment

最近の気になった話題(2021年第17-18週)

2021-05-09 | 興味深かった話題

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対応済だったからだろう)。

Comment