"それに見合ったRAMとストレージ" ここで調子に乗らないようにしようぜ。

eBayに出てるAMDの製品、結構手が届きそうな価格だよ！最近はRAMが高すぎるんだよね… 1TBのRAMを去年の10月に買わなかったこと、今でも後悔してる…

これは「これのBeowulfクラスターが必要だ」っていう2026年版だね。

しばらく待てば、これがeBayで安くなるよ。その頃には新しい1000コアのCPUが欲しくなってるだろうけどね。

7年前に何を夢見てたか覚えてる？1月にeBayでアンペアアルトラの80コアCPUが210€以下で売られてたんだよ。

ほんの数年待てば、今の価格のほんの一部で買えるようになるよ。その頃には「遅い」とか「電力を食う」って言われるようになるだろうし、なんで古いハードウェアを使ってるのか不思議がられるかもしれないけど、まだまだちゃんと動くからね。ここにある階段下のDL380 G7も、昔はすごく高かったけど、今は爪の先っぽで手に入れたようなもんだよ。

メモリのコストが高いのは置いといて、4世代目や5世代目のES CPUは、コア数に対してそんなに高くないよ。8480や8592はかなり手に入りやすいし、8480+ ESに192GBのメモリを8チャンネルで詰め込んだら、実際そんなに悪くないよ。

トレードオフだね。ハイパースレッディングはダイ上のスペースと電力予算を取るから。Eコア自体については、ARMのやり方だね。

すべては正確なワークロード次第だけど、ベンチマークを見るまでは自信を持って言えないな。一般的には、Eコアで問題ない2つのスレッドがあるなら、1つのハイパースレッディングされたPコアよりも、2つのEコアに分けた方がいいよ。

詳しい理由はわからないけど、計算集約型のタスクの中にはハイパースレッディングの恩恵を受けないものもあるんだ。もしそのプロセッサがそういうタスク向けなら、そのシリコンを実際に役立つ何かに使った方がいいよ。 https://www.comsol.com/support/knowledgebase/1096

EコアとPコアは、表面的にはARMのbig.LITTLEアプローチのように見える、2つのデザインチームの内部的な権力闘争だね。

その理由の一部は、ダイのサイズだと思う。288のEコアに対して72のPコア。最近はハイパースレッディングの脆弱性がたくさんあって、ハイパースレッド化されたデータセンターボードでは無効にされているから、これでリスクが完全に減るんじゃないかな。

「こういうのは特定のアプリケーションで競争力があるのか、好まれるのか？」ってことだけど、リンクされた話の中で非常に具体的なユースケースが挙げられてるよね：仮想化されたRAN。これは、5G+セルネットワークの制御プレーンにCOTSハードウェアとソフトウェアを使っているんだ。大量の速くて低消費電力のコアは、ネットワークノードがほぼリアルタイムで調整されるようなアプリケーションには確かに合うよ。これがこのデバイスのキーとなるユースケースかもしれないね。5Gネットワークは大きな利益を生むし、インテグレーターは工場から出たばかりのこういうデバイスを大量にフルリテール価格で買うだろうし。

ハイパースレッディング（Eコア）がないと、タスク間のパフォーマンスが一貫して良くなるんだよね。クラウドプロバイダーはこれを好む。なぜなら、他の人が重い作業を始めても「vCPU」が変動しないから。

ビルドサーバーみたいなアプリケーションでは、実際に重要なのはドルとワットあたりの整数計算の合計だけ。例えばYoctoプロジェクトをコンパイルする時、1つのコアが1つのCファイルをミリ秒でコンパイルするか1分かなんて気にしない。全体のマシンが何十万ものソースファイルをどれだけ早くコンパイルできるかが大事なんだ。EコアがPコアよりもドルとワットあたりの計算能力が高いなら、Eコアが欲しい。もちろん、少ない速いコアを持つことにはRAMが少なくて済むという利点もあるけど… 以前は512GBや1TBのRAMがかなり安く手に入ったけど、最近は実際に重要になるかも？でも、もし2つのEコアが1つのハイパースレッディングPコアよりも強力なら、Eコアを使うことでRAMを節約できるかもね？ハイパースレッディングは、結局のところ、CPUスレッドごとにコンパイラプロセスを立ち上げる場合にしかメリットがないから。編集：なんでこの視点にダウンボートする人がいるんだろう？別に怒ってるわけじゃなくて、ただ混乱してる。

HPC、特に物理シミュレーションでは、そっちが好まれるね。ハイパースレッディングのメリットはほとんどないし、高いクロック周波数が好まれる。だけど、これらの高コア数のCPUはクロック周波数が低いんだよね。

これはAmpereのARMサーバーと競合するのかな？特に通信業界では、たくさんの弱いコアの使い道があると思うよ。

確かに、場合によってはそれが正しい選択だよね。でも、クラウドにいる必要がある高いインターコネクトレートのシステムが出てくると、（クラウドの請求契約が固定されている機器とか、弾力的にスケールする必要があるコンピュート、DBのピザボックスと話すやつ、エッジ/CDN/キャッシュサービスなど、オンプレの真実のソースにたくさん落ちるもの）クラウドの帯域幅コストが痛くなってくるんだ。ビジネスプロセスマネジメントスタック（CRM、ADなど、君が挙げたような例）に限定してこのアプローチで成功したことがあるけど、データレートが「定期的な同期」や「メタデータのみ」を超えてクラウドとオンプレを橋渡しする必要が出てくると、思ったより早く痛みが出てくることが分かったよ。

クラウドは始めたばかりの時に正しい選択だね。インフラコストの問題じゃなくて、メンタルコストの問題。インフラを設定するのは、速度を落とすだけの余計なことなんだ。実際に負荷をかける時には、長期的な戦略について話し合う必要があるし、その点は正当なものだよ。

こういうコア密度の増加が、組織内のクラウドの議論で勝つ方法なんだ。各コアが遅すぎて意味のある仕事ができないなら、コア密度なんて意味がない。現実には、Intelはパフォーマンス対消費電力比でAMD/TSMCに3倍遅れてる。人々は高周波モデル（9575Fみたいな9xx5Fモデル）を見た方がいい。これは初めて約5GHzに達して、32コア以上でそれを維持できたサーバーCPUの第一世代だった。

あなたの計算には、自分のインフラを維持するためのエネルギーコストや人件費も含まれてる？

オンプレミスの主なコストは、機材の価格じゃなくて、その機材を管理するための人材を確保するコストだよね。ほとんどの企業は、サーバーを適切に管理するためのスキルが社内にないし、面接の時に良いインフラエンジニアを雇えるかどうかも分からない。もしスキルがある企業なら、スケーリングの例は逆効果になるよ。今日、3つのサービスを1つに統合できるなら、そんな少数のサーバーを管理するためにフルタイムのインフラスタッフが必要なの？それに、24時間365日の監視や災害復旧のためのレプリケーションも必要だよね。ほとんどのビジネスはITインフラをコアスキルや差別化要因として持っていないから、外注したいと思ってるんだ。

ただし、これらはすべてEコアで、シングルスレッド性能が悪く、AVX512などもサポートしていないことに注意してね。これがパフォーマンステストに大きく影響すると思う。いくつかのワークロードは問題ないけど、実際にハードウェアを使っている多くのユーザーにとっては、これが問題になる可能性が高い。もしあなたがそうなら、以前に発売されたGraniteRapids APプラットフォームは、同じスレッド数（6980Pで256スレッド）を達成できるよ。ただし、いくつかの注意点があって、まず「物理コアは128個しかない」こと、VMを使っているなら物理コアをVM間で共有したくないだろうし、次に500WのTDPがあって、17000ドル以上で販売されていること。販売されているものを見つけるのも難しいかもしれない。全体的に、本当に同じ条件で比較し始めると、特に100GbE以上のネットワーキングを試みると、クラウドプロバイダーに勝つのがかなり難しくなるよ。確かにマージンは大きいけど、彼らはあなたが払うよりもずっと安くハードウェアを手に入れているからね。こういう意見を見かけると、大抵はその組織がほとんど負荷のかからないアプリケーション用に速い現代的なCPUを持っていて、マシンはほとんどアイドル状態で、ネットワークはマシンが処理できるトラフィックの1/100にも達していないことが多い。これを解決するのは、主に技術的な問題ではなく、「クラウドが悪い」という問題じゃないんだ。

人材がいるかどうか分からないな。うちの職場ではHyperVを使ってるけど、実際にHyperVを知ってる人を見つけるのは難しくて高いんだ。Ciscoのネットワーキングやストレージアプライアンスも加えると、99.99%の稼働率を確保するのは大変だよね。しかも、1人だけじゃなくて、スタッフのギャップを避けたいなら少なくとも2人、できれば3人は必要だし。それに、その運用にはクラウドの人たちも必要だよ。うちはこういうハイブリッドなセットアップをしていて、両方の良いところを少しずつ得ているけど、結局オンプレミスやコロケーションのインフラを管理するのは本当に面倒くさい。ビジネス環境のためにやってるだけなんだ。

クラウドについて驚いたのは、コアの価格がどんどん上がっていることなんだよね。でも市場の流れは逆で、昔は1/2や1/4の価格だったのが、今は1/256になってるし、しかも速くなってる。それなのにクラウドのコアの価格は上がり続けてる。彼らのビジネスプランは、オンプレミスの機械を維持していた人たちを排除して、どんどん安くなっているものに対して同じような価格を取り続けることだと思う。クラウドのハードディスクやSSDの価格には本当に驚かされるよ。サーバーのCPUの価格が小さいシステムでCPUを買う場合の2倍くらいなのに、ドライブスペースはローカルでやるのに比べて10倍から100倍の価格になってる。冗長性は少し高いけど、そのオーバーヘッドでデータを何度も繰り返すことができる。時間が経つにつれて、クラウドの取引条件は、ハードウェアがコア数を増やすにつれて悪化しているね。

288コアのボックスを使って、複数の並列ワークロードに分けるのに仮想化を使うのが唯一の良い方法なのかな？一度、GCPで384コアのAMD EPYCのベアメタルVMを借りたんだけど、ベアメタルLinuxだけでは並列化されたワークロードをスケールさせるのが全然できなかったんだ。CPU推論のジョブを並列で走らせたかったんだけど（それぞれ16コア使う予定だった）、スケーリングがひどくて、並列ジョブを増やせば増やすほど、全体が遅くなっちゃった。htopをチェックしたらCPUは全然使われてなくて、俺の理論ではONNX/torchでメモリのボトルネックが起きてるんじゃないかと思った（NUMAノードに関係してるのかな？）。結局、そこではproxmoxやvmwareを使ってCPUやメモリのリソースを分けるテストはできなかったから、代わりにコア数の少ないAMD Ryzen 1Uをたくさん買うことにしたんだ。そっちの方が俺の単純なアプローチにはずっとスケールが良かったよ。

Linuxは1024コアまでちゃんと扱えると思うよ。

ここには根本的なボトルネックはないと思う。1つのコアに100のプロセスがある時のスケジューリングオーバーヘッドは、100のコアに100のプロセスがある時よりも多いから。ボトルネックはほとんどハードウェア関連で、熱や電力、メモリ、他のI/Oに関係してる。だから、実際には「288コア」のパフォーマンスは得られないんだ。つまり、288コアでビットコインを単一コアと同じ速さで掘ることはできない。むしろ、288のタスクが断続的に作業をする時のコンテキストスイッチングオーバーヘッドが少なくなるってこと。これがほとんどのハードウェアの使われ方だしね。

確かにボトルネックはあるよね。いつも思うのはカーネルのネットワークスタックだな。独立したワークロードが何百もあるのに、カーネルのTCPスタックを使う意味がないよ。20年前にラックの上に外部TCPアプライアンスを置くのと同じくらい意味がない。ユーザースペースのプロトコルスタックが勝つよ。

次のボトルネックはシリコンではなくソフトウェアのスケジューリングになるのかな。 うん、スケジューリングはしばらく問題になってるね。数年前に、Linuxカーネルが偶然8コアにハードコーディングされていたっていう素晴らしい記事があったよ。多分ググれば見つかると思う。今一番興味深い問題はキャッシュだと思う。タスクがコアを移動するたびにキャッシュミスが発生するからね。数千のスレッドが数百のコアの間を数ミリ秒ごとに切り替えていると、CPUキャッシュを無駄にして再読み込みする時間が増えてきて、危険な状態に近づいているよ。

そうだね、スケジューリングの問題やNumaの問題など、ボックス型のクラスターによって引き起こされる問題があるよ。数年前に大きなパフォーマンスの問題があって、プロセスをNumaゾーンのトポロジーにマッピングすることで解決したんだ。そうしないと、ソフトウェアのデフォルト設計がすべてのメモリアクセスを同じNumaゾーンにルーティングしちゃって、パフォーマンスが落ちちゃうからね。

それはいいポイントだね。Linuxがio_uringを導入したけど、これでレイテンシをうまく隠すためのネイティブなプリミティブが得られると思う？でも、それはパズルの一部に過ぎないかな。

チップレットの話を読んだ瞬間、これを思い出した！インテルもチップレットアーキテクチャが未来だって認めてるのが嬉しいね。

コアが十分にあれば、L1をまとめて即席のRAMにできるかもね！

新しいサーバーCPUって、置き換え用じゃないの？だから、データセンターは古いCPUを外して新しいのを入れて、既存のRAMの設定には手を加えずに、既存のRAMの範囲内でより良いパフォーマンスを発揮できるってことだよね。で、RAMの価格が下がったら（それにはちょっと時間がかかるかも）、その時に別にRAMをアップグレードすればいいんじゃない？

私の経験では、RAMのコストはサーバーを買うビジネスにはほとんど影響しないよ。購入のタイミングは契約や保証のサイクルでほぼ決まってるから。