一般のユーザーの用途であれば
性能低下が発生することはあまりない
性能低下は特にI/Oで顕著である。たとえばGPUを利用するプログラムで、GPUのデータを読み込む(あるいはGPUにデータを少しだけ書き込む)というケースを考える。
大量のデータであれば素直にDMAをかけるわけだが、そのDMAの完了通知や、逆にDMAを始めるリクエストなどは、プログラムからデバイスドライバー経由でGPUに渡すか、GPUからデバイスドライバー経由でプログラムに渡ることになる。
Page Tableが一緒であれば、ドライバーとアプリケーションの間では原則としてデータ移動は発生しない。単に値が格納されたアドレスを受け渡せば済むからだ。
ところがPage Tableが別になってしまうと、もはやアドレスを受け渡すことができなくなる。したがってアプリケーションとドライバーの間で、データのコピーが発生することになる。このデータのコピーの頻度が高くなるほど、性能へのインパクトが大きくなる。
Postgresqlでの性能低下も、HDDをぶん回すSQLデータベースでの結果ということを考えると、確かにありえる数値ではある。あるいは加藤勝明氏のMentionについても、GPUをフル駆動させている状況としてはありえる話と言えよう。
今のところ、この影響を受けるのはインテルの投機実行をサポートする、しかもOut-of-Orderのマシン、要するにCore 2以降の全部(Atomについては古いものは大丈夫だろうが、Silvermont以降でも大丈夫かは確認できていない)と、ARMのCortex-A75が今のところ対象となっている。
ただARMの場合、アーキテクチャーライセンスを受けてベンダー独自にインプリメントした製品も多いので、今後対象が増える可能性もある。
また今回は挙げられていないが、IBMのPowerやMIPS、あるいはIBM/NXPのPowerPCなども潜在的には今回の脆弱性を持っている可能性があるわけで、このあたりは各ベンダーのレポートを待ちたいところだ。
性能低下がどの程度か、というのは一律にはいい難いが、多少なりとも影響があるのは事実ではある。前述の加藤氏のケースでは、FF14ベンチでのスコアーが21237→20400なので、4%ほどのダウンである。
とはいえ、一般のユーザーの使われ方であれば、Postgresqlほどの性能低下が見られるケースはそう多くはないはずだ。とりあえず最新のパッチは当てておくに越したことはないだろう。
本記事はアフィリエイトプログラムによる収益を得ている場合があります

この連載の記事
-
第885回
PC
TSMCも次世代「CFET」の全貌を披露! Forksheetスキップの背景と、世界最小6T SRAM実証で見えた2030年への布石 -
第884回
PC
Samsungが次世代CFETの試作に成功! IBMの10万ドル方式に対抗する、量産重視な「一括形成プロセス」のリアリティ -
第883回
PC
TSMCのA16プロセスの詳細が判明! 性能向上の主因はトランジスタではなく裏面電源供給(SPR)にあり? -
第882回
PC
IBMが0.7nmチップの製造に成功! 変態的CFET構造NanoStackの凄みと、あまりに高すぎる製造コストの壁 -
第881回
PC
同一周波数で消費電力18%削減! 進化した「Intel 18A-P」はどこが変わったのか? -
第880回
PC
次世代NVLinkの布石か? TSMCの光電融合技術「COUPE」がもたらすAIサーバーの光接続 -
第879回
PC
なぜAIには「光」が必要なのか? NVIDIAが解説するスケールアップネットワークの低遅延・省電力化戦略 -
第878回
PC
もはや銅配線は限界? 3200Gイーサネット実現に立ちはだかる200GT/秒の壁 -
第877回
PC
「不良品ゼロ」と「水冷NG」の狭間で。ルネサスが明かした車載チップレットSoCのリアル -
第876回
PC
このままではメモリーが燃える! HBM4/5世代に向けた電力供給の限界と、Samsungが示すパッケージ協調設計の解 -
第875回
PC
1000A超のAIプロセッサーをどう動かすか? Googleが実践する垂直給電(VPD)の最前線 - この連載の一覧へ











