アカウント名:
パスワード:
要するにGather命令を許すと脆弱性になるから他の複数命令に書き換える訳で、それを使ってない場合は特に影響がない訳でしょ。Gather命令がどれだけマイナーなのか分からないけど、最大50%ってのはかなり極端なケースだと思うなぁ。Intelもそう言ってるしその通りだと思う。
とりあえずAVX2の命令っぽい。こういう命令ってある特殊な処理を大幅に高速化したりするからそういうケースだと被害がデカいのかしら。拡張命令系はJITが上手いことやってくれたり、内部で分岐したり、複数バイナリが同梱されていたりするよね。こういう「外観上サポートされてるけど実際は脆弱性があるので低速な場合」ってどう処理するんだろう。CPUID的な何かで良しなにって感じか、普通に低速に実行されるのか。そこら辺うまいことやってくれたら多少パフォーマンスへの影響は緩和されるかもね。
他の命令に書き換えるのではなくメモリバリアが追加されるらしい
なんかググったら、実装初期の世代だと「動くけど遅くなる事がままある命令」だったっぽい。実装内容もXeonだとどうのみたいな解説も引っ掛かる。
本格的に使うなら環境決め打ちかJITでコード生成だろうけど、コード生成ならJIT前のベンチマークでほっといても直ったり、条件別の利用可否しててもその条件リストだけ直せば対処できそう。
50%低下はこの命令がクリティカルパスでぶん回る場合だろうけど、更に代替実装が無いあるいは使用不可とかの条件も重ねないとそうはならん。気になるレベルの性能低下は中々無さそうだ。
50%程度ならまだIntelのほうが速そうだなぁZenのGather命令はとんでもなく遅い
「leaks the content of the internal vector register file during speculative execution」ってあるから、内部レジスタのうちユーザからアーキテクチャレジスタとして見える、あるいは後から見えるようになる領域でGather作業するようにμop組んじゃったんじゃないかね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
最大50% (スコア:0)
要するにGather命令を許すと脆弱性になるから他の複数命令に書き換える訳で、それを使ってない場合は特に影響がない訳でしょ。
Gather命令がどれだけマイナーなのか分からないけど、最大50%ってのはかなり極端なケースだと思うなぁ。
Intelもそう言ってるしその通りだと思う。
とりあえずAVX2の命令っぽい。
こういう命令ってある特殊な処理を大幅に高速化したりするからそういうケースだと被害がデカいのかしら。
拡張命令系はJITが上手いことやってくれたり、内部で分岐したり、複数バイナリが同梱されていたりするよね。
こういう「外観上サポートされてるけど実際は脆弱性があるので低速な場合」ってどう処理するんだろう。
CPUID的な何かで良しなにって感じか、普通に低速に実行されるのか。
そこら辺うまいことやってくれたら多少パフォーマンスへの影響は緩和されるかもね。
Re: (スコア:0)
他の命令に書き換えるのではなくメモリバリアが追加されるらしい
Re: (スコア:0)
なんかググったら、実装初期の世代だと
「動くけど遅くなる事がままある命令」
だったっぽい。
実装内容もXeonだとどうのみたいな解説も引っ掛かる。
本格的に使うなら環境決め打ちかJITでコード生成だろうけど、
コード生成ならJIT前のベンチマークでほっといても直ったり、
条件別の利用可否しててもその条件リストだけ直せば対処できそう。
50%低下はこの命令がクリティカルパスでぶん回る場合だろうけど、
更に代替実装が無いあるいは使用不可とかの条件も重ねないとそうはならん。
気になるレベルの性能低下は中々無さそうだ。
Re: (スコア:0)
50%程度ならまだIntelのほうが速そうだなぁ
ZenのGather命令はとんでもなく遅い
「leaks the content of the internal vector register file during speculative execution」ってあるから、内部レジスタのうちユーザからアーキテクチャレジスタとして見える、あるいは後から見えるようになる領域でGather作業するようにμop組んじゃったんじゃないかね。