つっても、非公開のを別につけているわけではない。
Copyright 1999- Jun Makino
2024/05 2024/04 2024/03 2024/02 2024/01 もっと昔なんか全体になにもかも AI のためにみたいなってたけど LLM はどこに いくのかしらね。推論はともかく BP 学習はもうちょっと賢い方法が そろそろでてきそうな気はする。
どのタイプのを一基いくらで作るつもりなのか、、、
去年のSFF のシンポジウムでも話をしたんだけど、折角先端ロジックと先端DRAMをもってる世界唯一の企業なんだからそれを有効に使って欲しいところ。
選挙期間の行動と当選後次の選挙直前までの行動があまり関係なさそうな 人なわけで、、、
研究者でも、こう、申請者書いてプレゼンして予算とってくるのは素晴らしくうまいんだけどそれそもそも実現可能だっけ？という人っているよね。なんかそういう感じ。
まあ話は簡単で、MIMD か SIMD かと、分散メモリか分散共有メモリ (Stanford DASH 的なあれ)、オンチップネットワークのトポロジとルーティン グの仕掛けくらい。
これに対して、どういう物理的制約があるかというと、最大のものはチッ プの端から端まで信号を動かすための時間と電力である。
せいぜい 30mm しかないか ら光速なら100ps なんだけど、配線が細くなると抵抗は大きくなって、グラウ ンドプレーンとの寄生容量は単位長さ当りでかわらないので、配線の面積の 2乗に反比例して抵抗が大きくなって、電流が減るので遅延時間が増える。
例えば 10TB/s のレートで20mm データ動かすとする。クロック 2GHz と してみる。80Tbit/s なので、4万本線がいる。これを 5mm 幅にいれたとする と 1mm あたり 8000本で、 125nm 間隔である。
銅の抵抗率 2e-8 Ω・m なので、1辺60nm の正方形で長さ30mm とすると 抵抗は 170kΩ、キャパシタンスは 6pF くらい。電圧(実際には線型なので消 える) 1V として充電するのにかかる時間スケールは Q=CV = TV/R から T= CR となって、概ね 1us である。全く話にならない。
伝播時間は配線長の二乗に比例するので、遅延時間がクロックサイクルで ある 2GHz より短くなるためには大体1/√2000 の 0.67mm間隔で45段パイプラ インレジスタをいれると必要があり、22.5ns くらい遅延がはいる。
消費電力は 1V振幅だと 3pJ/bit くらいであり、240W になる。わーお。 0.65Vなら100W。
このことをは何を意味するかというと、チップ全体くらいのスケールでデー タが移動するようなメモリシステムでは、半導体テクノロジーがなんであれ バンド幅は 10TB/s くらいを超えることは難しい、ということである。
チップサイズを半分にすれば、配線のキャパシタンスは半分になるの一方 電力バジェットは 1/4 になるので、5 TB/s が可能で、4チップ合わせると 20TB/s にできる。
つまり、今後メモリバンド幅を維持する、ないしはあげていくためには、 物理的にメモリを共有する範囲を小さくし、大距離のデータ移動をなくして いくことが必須になる。
さて、2次元のチップで、プロセッサ並べるので、ネットワークとして 単純に考えられるのはメッシュネットワークである。メッシュネットワークで の汎用並列計算機は PACS/PAX や Intel touchstone、Cray T3D 等の数多くの 成功例がある確立した方法論であり、それでよさそうな気もする。
が、例えばPEが1万個、 100x100 のネットワーク、となると、今度は 1ホップ毎の遅延の問題が発生する。例えば5クロックでルーティングできたと して(ありそうにないが)、端から端までだと1000クロック、500ns かかるから である。
もちろん、「京」や富岳のような大規模並列計算機でメッシュネットワー クを採用するのに比べると1ホップの遅延は1桁以上小さくできると考えられる が、段数はむしろ多くなるので、それほど遅延が小さくならない。
一方、(ファット)ツリー的なネットワークでは、配線のトータルの長さは 本質的にメッシュの場合とあまり違わないが、ロジックがはいる段数が圧倒的 に小さいため、上で述べた 45段とか90段程度の遅延で端から端までデータを 送ることができる。つまり、レイテンシが 1/10 程度になる。
有効にバンド幅を使えるかどうか、特に袖交換についてどうかを考える。 簡単のためPE数を 4096とする。空間2次元の問題であれば、メッシュネットワー クは自然なマッピングで、一番具合がよいであろう。
3次元になると、それでも分割は2次元のままにするか、3次元にするかの 2通りである。2次元のままのt時には、全体ボックスの1辺を1として、 1 x 1/64 の面積が各方向に交換される。
一方、3次元にすると、例えば xy で 16x16 の領域を z 方向に16面とっ て、 z方向の通信は16個先と、となり、z方向のバンド幅は 1/16になる。面積は 1/4 だがz方向は4倍時間がかかる。一方 x, y 方向は 1/4 になるので、合計 は 4 が5になるくらいであまり増えない。
とはいえ2次元分割のままがベストであるといえる。
一方、3段のツリーネットワークで、各レベルで任意のノードが他の任意のノー ドに(衝突しないとして)送れるものを考える。バンド幅は、一番下がメッシュ で想定した1リンクと同じ、1段上がる毎に4倍になるとしよう。
2x2x4 の分割を繰り返すので、トップレベルでは 表面積が 0.5*0.5*2+0.25*0.5*4=1 で、通信速度は16なので時間は 1/16。メッシュだと 1/64 なので4倍遅い。ハードウェア量としてはバンド幅もう2倍にしても いい気がするが、そうすると速度差は2倍。
あ、周期境界を想定するとメッシュは多分実効通信速度が半分になるので まあ同じか。レイテンシはメッシュでは16個先に送ることを考えると大きくは かわらないかまだメッシュが大きい。
要するに、メッシュとツリーを比べると、空間2次元の袖交換だとメッシュ がよいが、3次元以上になると配線資源、電力を同程度にするとあまり変わら ない。
これはバイセクションバンド幅を大きく変えなければ、という前提がある ので当然ともいえる。逆にいうとバイセクションが同じ時にメッシュは電力・ 配線資源的にツリーより大きく有利にはならない。
こう書いてしまうと滅茶苦茶当たり前だ。
ただ、これ、面積へのインパクトはP&Rの方法に依存するんだけど、メッ シュはPEの中で他の配線と一緒に最適化できるのに対してツリーは普通は配線 エリア別にとるので、そっちですごく不利になる。
これはだから、PEの中にツリーネットワーク用の配線やロジックを用意し とけ、ということか。ふむ。
あるいはもっと大きなブロックでというか複数の階層をフラットに展開し てP&Rしろと。まあこのほうがいいのは明らかなんだけど今のツールの処理能 力ではできないんだよねこれ。
大規模並列化したアニーリングで P&R するようなツールがないといけな い。というかあれば本来もっと、、、
うーん、アーキテクチャの話がP&Rツールの話になってしまった。まあ実 際 LSI 設計ツールって問題多い。最大の問題はまともに並列化されて ないのでクラスタで動かすとかできなくてすごく遅いこと。
NHK『新プロジェクトX』波紋 「真ん中でガッツポーズ決めてた」中心人物、なぜか一切登場せず家族から疑問の声 スパコン『京』めぐり
こういう反応がでる、ということを全く想像してなかったんだと思うけど、 技術者本人はともかく社として広報担当とかはちゃんとリスク管理できてないといけな かったのではという気が。
歴史の修正というのはこんなふうに起こるという話ではある。
まあそもそも「京」は成功だったのかとか開発方針として正しかったのかという話は別にあるべきではある。
何が本当に起こったのかは知るすべはないが、「反社会的勢力との関係が真実か否かは問題ではな」いというのは要するに真実じゃなかったという以外の解釈はないよね、、、
「不審な懲戒でトップが左遷」って文字になってるとすごい。
2007年は木村さんが次世代テクニカルコンピューティング開発本部長。 2008年から井上さん、2011年から追永さんと。
【開発物語】富士通のスパコン「京」 逆転の発想、周波数下げ省電力 (1/7ページ)
井上さんの回想としては:０５年末に話を聞いて「私も、ほかの技術者も、 とてつもなく魅力を感じた」。すぐに、上司の山中明本部長（当時）に「やら せてほしい」と直訴したが、会社の反応は鈍かった。
(引用続き)当時、インテル系ＭＰＵでスパコン並みの高性能機を販売していた富士通だが、「真っ正面からスパコン開発なんてとんでもない」「そんな暇があるのか」といった否定的な意見も少なくなかった。
(引用続き)０６年になってようやく山中本部長から「検討しろ」と指示が出た。サーバーシステム事業本部のＬＳＩ（大規模集積回路）部隊と富士通研究所の技術者を主体に次世代テクニカルコンピューティング開発本部が発足したのは０７年７月。理研のプロジェクト始動から１年以上たっていた。
企業の中では色々なことが起こるというのはまあそういうものでだからど うというわけではないが、計算機アーキテクチャには責任者の影響は割と大き くて、 FX100にしても A64fx にしても井上さんがいればこうはなってなかっ たんじゃというところがある。
まあそれなら井上さんがやってたら売れるものになったかというとそれはそれ。
新プロジェクトX スパコン「京」の回 感想と思い出 「この辺ちょっと温度差があるが、おそらくはプロジェクト内での立ち位置での視点の違いで、インターコネクトやソフトウェア等をやっていたメンバーからすればCPU開発のリーダーは相対的に重要ではなかったのかもしれない。」
もちろん死んだんだけど、まあそれが転生したのが HBM でこれが2014年にはアナウンスされる。
10年たって SK Hynix Mulls 'Differentiated' HBM Memory Amid AI Frenzy これは、 HBM4 はロジックダイの上に直接積層もあるかも?的に書いてる。
でも最先端ロジックのダイに HBM4 の物理インターフェースでDRAM載せる とエリアペナルティが大き過ぎるんじゃないかという気が。 Winbond の CUBE みたいに HBM2 といいながらカスタム設計とかでないと。
まあでも SKとか標準品しか作らないだろうし。うーん。
まあ学術会議があんまり機能しなくなってるのは確かで、それはこれまでの政府による「改革」の「成果」なわけで、だからもういらないよね、というのはもちろん本来逆ではある。
HBM4 のベースダイはHBM3 までと違って DRAM プロセスじゃなくてロジッ クプロセスでつくるという話。「Cost effective」 でも 12FFC+で、HBM4の1モジュール一体一個いくらになるんだろうという、、、
で、まあ、これつくるのでTSMCのラインが一杯だというのは想像できる。そういうことね、、、
とはいえこれは問題の解決にはならないわけで、ということで解決を提案するとそれはまだ先の話ねといわれるということもあってなかなか世の中は難しい。そういうものではある。
チップ内とかパッケージ内で配線ひけるところで配線以外のほうがよくな るというのは原理的にはあるかもしれないけど現実にあるとは思えないし、 配線の消費電力を下げるには信号振幅減らせばいいんだからまだ 1桁くらいは 下がる気が。PAM4 とかできるんだから振幅下げられるよね？
2時間弱費やしたあとで、「IPアドレスが間違っていた」ことに気が付い たのでありました。むーん。サーバーは 69 だったのに68でアクセスしようと していた。それはつながらないよね、、、
Base tile は Intel 7, 640mmsq. L2D 144MB。この上に Compute tile (x8) と RAMBO tile なるものがのっている。RAMBO は L3 と書いてある資料 もあるが、L2 の容量が 408MB というのは base tile の 144MB と RAMBO tile の 60MB の合計の2倍であろう。
Compute die と base die はピッチ 36um の Foveros なるもので接続。 これは要するにマイクロバンプであろう。 L2D BW が 13TB/s なので、Compute tile 毎に 1.6TB/s。Compute tile は 60mmsq くらいなので、この面積でマイクロバンプで 1.6TB/s だすのは結構大 変だと思う。
例えば 2GHz のデータレートだしたとして6400個必要で、8mmsq くらい。 ただ、おそらくこれが大きな問題ではなくて、この L2D がおそらく共有キャッ シュであることが問題であろう。
すごく大雑把にいって、チップ上(でも基板上でもどこでも)1ビットが 10mm 動くと 1pJ 消費する。13TB/s で 15mm 動くと160W くらい食う。
HBM2e 8 個で 160W はいくと思うので、L2から下だけでTDP 600W の 半分を喰っている。
登場時期は、Intel N5 なので22年であればそんなところで、特に遅くは ない。
かなり驚きなのは、そういうわけで L2Dを含まない、演算コアと L1だけ の Compute tile だけで800mmsq で、 NVIDIA H100 の全面積とかわらないこ とである。クロックとピーク性能はあんまりかわらないので、かなり面積効率 は低い(N4とN5なので密度はあんまりかわらない)
まあ、演算性能同程度で L2D$ が7倍とかバンド幅も倍くらいとかでダイ サイズ2倍とかの構成で、どうやって電力バジェットに納める気だったのかと いうかこれ面積決まった時点で無理じゃないかという気がする、、、
1ノード2ソケットで 384コアとかになるのか。Xeon Phi が 72コアで多いと思っていたのはもう遠い昔のことみたいな。
作業・対応色々一杯遅れててすみません＞各方面。