アカウント名:
パスワード:
「Skylake CPUで複雑な処理を実行させると～」ってタイトルと矛盾してね?つーか「複雑な処理」って何言いたいのかワケわからんけどな、タレコミ者がアホなのだろう。
とりあえずPrime95でのフリーズの再現性が確認された。原因はまだ不明。(あるいはIntelは掴んでるかも知れないけど、一般には公開されていない。公開すると悪用されて危険なのは自明)
簡単な処理で凍るんだったら、もっと早くに問題が顕在化したに違いないから、Prime95にしかないような何か複雑な処理が原因なのだろうと推測される。
という風に読み取れないほどのアホが存在するとは思わなかっただけだろ?
Prime95 ってオープンソースなんだし問題の絞り込みは可能でしょ。ソース見ると CPU_FLAGS っての参照して AVX 命令使えるかとか判断して使える命令切り替えてるから先ずは AVX 使わなかったらフリーズしないのか、とか辺りから。
簡単な処理で凍るんだったら、もっと早くに問題が顕在化したに違いないから、
ドイツのPCエンスー向け掲示板で発見されて、Prime95界隈で再現手法が確立された。公開されているのは、Prime95でAVXとHTを使って特定のパラメータを指定してスレッド数をCPUの上限である8スレッドでしばらく回すと固まるということ。これに対してIntelは既に新しいマイクロコードを書いたので配るべく努力していると言ってる。Quarkみたいにどうopcodeを並べると死ぬかは公開されてない。公式のエラッタもまだ出てない、と思う。
大原考察ではそういうことらしいので、クロックを上げるとある程度から指数的に熱が増えるで、そうなっても性能が伸びないのを防ぐためにデコーダを豪華にしてパイプラインを伸ばしたで、最近のCPUは熱暴走しないよう温度を見てクロックを落とす動作をするんだけど、FIVRのオミットで制御粒度が荒くなった。にもかかわらず熱制御は5xxxシリーズレベルでピーキーになっていて周波数を落とすのが間に合わないか、とある重たいopコードが優先されて落とせないか、そんな感じでしょう。高速プロセスなら問題なかったかもしれない組み合わせがSoCプロセスではダメだったと。バリデーションの見落としですかね。
microcodeで温度制御を優先すればフルロードでも落ちないでしょうし、HTでカリカリに使わない下位モデルでは多分落ちない。温度制御を無効にするようなopcodeのせいだと下位でも落ちる可能性がありますけど、i7でしか確認されてないのでTjunctionからの周波数降下が間に合ってないんでしょうか。
スレッド数と与えるパラメータも決まっていることが熱暴走説だと説明できないような……?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
この問題が発生する理由は不明? (スコア:0)
「Skylake CPUで複雑な処理を実行させると～」ってタイトルと矛盾してね?
つーか「複雑な処理」って何言いたいのかワケわからんけどな、タレコミ者がアホなのだろう。
Re: (スコア:0)
とりあえずPrime95でのフリーズの再現性が確認された。原因はまだ不明。
(あるいはIntelは掴んでるかも知れないけど、一般には公開されていない。公開すると悪用されて危険なのは自明)
簡単な処理で凍るんだったら、もっと早くに問題が顕在化したに違いないから、
Prime95にしかないような何か複雑な処理が原因なのだろうと推測される。
という風に読み取れないほどのアホが存在するとは思わなかっただけだろ?
Re: (スコア:-1)
とりあえずPrime95でのフリーズの再現性が確認された。原因はまだ不明。
(あるいはIntelは掴んでるかも知れないけど、一般には公開されていない。公開すると悪用されて危険なのは自明)
Prime95 ってオープンソースなんだし問題の絞り込みは可能でしょ。ソース見ると CPU_FLAGS っての参照して AVX 命令使えるかとか判断して使える命令切り替えてるから先ずは AVX 使わなかったらフリーズしないのか、とか辺りから。
簡単な処理で凍るんだったら、もっと早くに問題が顕在化したに違いないから、
Re: (スコア:4, 参考になる)
ドイツのPCエンスー向け掲示板で発見されて、Prime95界隈で再現手法が確立された。
公開されているのは、Prime95でAVXとHTを使って特定のパラメータを指定してスレッド数をCPUの上限である8スレッドでしばらく回すと固まるということ。
これに対してIntelは既に新しいマイクロコードを書いたので配るべく努力していると言ってる。
Quarkみたいにどうopcodeを並べると死ぬかは公開されてない。公式のエラッタもまだ出てない、と思う。
14nmはハイパフォーマンスプロセスの開発が放棄されたらしい (スコア:1)
大原考察ではそういうことらしいので、クロックを上げるとある程度から指数的に熱が増える
で、そうなっても性能が伸びないのを防ぐためにデコーダを豪華にしてパイプラインを伸ばした
で、最近のCPUは熱暴走しないよう温度を見てクロックを落とす動作をするんだけど、
FIVRのオミットで制御粒度が荒くなった。にもかかわらず熱制御は5xxxシリーズレベルでピーキーになっていて
周波数を落とすのが間に合わないか、とある重たいopコードが優先されて落とせないか、そんな感じでしょう。
高速プロセスなら問題なかったかもしれない組み合わせがSoCプロセスではダメだったと。
バリデーションの見落としですかね。
microcodeで温度制御を優先すればフルロードでも落ちないでしょうし、HTでカリカリに使わない
下位モデルでは多分落ちない。
温度制御を無効にするようなopcodeのせいだと下位でも落ちる可能性がありますけど、i7でしか確認されてないので
Tjunctionからの周波数降下が間に合ってないんでしょうか。
Re:14nmはハイパフォーマンスプロセスの開発が放棄されたらしい (スコア:2)
スレッド数と与えるパラメータも決まっていることが熱暴走説だと説明できないような……?