アカウント名:
パスワード:
「Skylake CPUで複雑な処理を実行させると～」ってタイトルと矛盾してね?つーか「複雑な処理」って何言いたいのかワケわからんけどな、タレコミ者がアホなのだろう。
とりあえずPrime95でのフリーズの再現性が確認された。原因はまだ不明。(あるいはIntelは掴んでるかも知れないけど、一般には公開されていない。公開すると悪用されて危険なのは自明)
簡単な処理で凍るんだったら、もっと早くに問題が顕在化したに違いないから、Prime95にしかないような何か複雑な処理が原因なのだろうと推測される。
という風に読み取れないほどのアホが存在するとは思わなかっただけだろ?
Prime95 ってオープンソースなんだし問題の絞り込みは可能でしょ。ソース見ると CPU_FLAGS っての参照して AVX 命令使えるかとか判断して使える命令切り替えてるから先ずは AVX 使わなかったらフリーズしないのか、とか辺りから。
簡単な処理で凍るんだったら、もっと早くに問題が顕在化したに違いないから、
ドイツのPCエンスー向け掲示板で発見されて、Prime95界隈で再現手法が確立された。公開されているのは、Prime95でAVXとHTを使って特定のパラメータを指定してスレッド数をCPUの上限である8スレッドでしばらく回すと固まるということ。これに対してIntelは既に新しいマイクロコードを書いたので配るべく努力していると言ってる。Quarkみたいにどうopcodeを並べると死ぬかは公開されてない。公式のエラッタもまだ出てない、と思う。
趣味で、AVX を使った OTFFT という FFT ライブラリを開発してるんですが、Haswell や Ivy bridge では問題ないのに Skylake だと系列長が 2^18 以上になると急激な性能劣化を起こします。クロックの低い Haswell に敵わなくなるんですよ。もちろん、Core i7 でのベンチマークなので HT も使ってます。キャッシュのアルゴリズムが変わったせいかと思ってたんですが、何か、このフリーズのバグと関係あるかもしれない。ちなみに、FFTW でも同様の現象が観測できます。
つまりSkylakeでもAVX非対応のPentium/Celeronはセーフ、HT非対応のCore i5もセーフとみていいのかな。
一瞬、i7の対策版が出るまで買い控えようか迷ったけど、Haswellでもエラッタが出てたので複雑なものとしてバグは避けがたいのかも。結局欲しい時が買いどきか。
大原考察ではそういうことらしいので、クロックを上げるとある程度から指数的に熱が増えるで、そうなっても性能が伸びないのを防ぐためにデコーダを豪華にしてパイプラインを伸ばしたで、最近のCPUは熱暴走しないよう温度を見てクロックを落とす動作をするんだけど、FIVRのオミットで制御粒度が荒くなった。にもかかわらず熱制御は5xxxシリーズレベルでピーキーになっていて周波数を落とすのが間に合わないか、とある重たいopコードが優先されて落とせないか、そんな感じでしょう。高速プロセスなら問題なかったかもしれない組み合わせがSoCプロセスではダメだったと。バリデーションの見落としですかね。
microcodeで温度制御を優先すればフルロードでも落ちないでしょうし、HTでカリカリに使わない下位モデルでは多分落ちない。温度制御を無効にするようなopcodeのせいだと下位でも落ちる可能性がありますけど、i7でしか確認されてないのでTjunctionからの周波数降下が間に合ってないんでしょうか。
スレッド数と与えるパラメータも決まっていることが熱暴走説だと説明できないような……?
じゃあ外から液体窒素でも何でも使ってガンガンに冷やせばフリーズしなくなる、或いはフリーズする可能性が下がるってことかなあ? やろうと思えば可能な検証方法だと思うが。
大原考察ではそういうことらしいので、
大原って雄介? およそ技術的なことはなんも分かってないライターの名前は出すべきではないかと。
じゃあSkylakeはクロック落とせばPrime95でフリーズしなくなんの??
マルチスレッドでフリーズといえばデッドロック。この問題にぶち当たると、なぜ、どういうタイミングで起きるのか、全くわからないことが多い。
特定のコードシーケンスで発生するならスレッド数を最大にしなくても発生しそうなものだし、リソースの競合なら「しばらく」実行しなくても発生しそうな気が。CMOSは高温になると動作条件が厳しくなるので、CPUをフルに使うのも「複雑な処理」と言えるでしょうね。Prime95って設定した上限温度に達するとベンチを停止する機能があって、グリスのCPUでAVXやHT有効だとどんどん温度が上がっていきました。Prime95はそこらのベンチよりも相当負荷が高そうなベンチなので…
特定のコードシーケンスで発生するならスレッド数を最大にしなくても発生しそうなものだし、リソースの競合なら「しばらく」実行しなくても発生しそうな気が。
複数のコアから利用されるリソースのシェアに完全でないところがあり確率的に不具合が発生するとかが原因なら「スレッド数最大」&「「しばらく」実行」でフリーズするというのもあることだと思うよ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall
この問題が発生する理由は不明? (スコア: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を並べると死ぬかは公開されてない。公式のエラッタもまだ出てない、と思う。
Re:この問題が発生する理由は不明? (スコア:3, 興味深い)
趣味で、AVX を使った OTFFT という FFT ライブラリを開発してるんですが、
Haswell や Ivy bridge では問題ないのに Skylake だと
系列長が 2^18 以上になると急激な性能劣化を起こします。
クロックの低い Haswell に敵わなくなるんですよ。
もちろん、Core i7 でのベンチマークなので HT も使ってます。
キャッシュのアルゴリズムが変わったせいかと思ってたんですが、
何か、このフリーズのバグと関係あるかもしれない。
ちなみに、FFTW でも同様の現象が観測できます。
Re:この問題が発生する理由は不明? (スコア:1)
つまりSkylakeでもAVX非対応のPentium/Celeronはセーフ、HT非対応のCore i5もセーフとみていいのかな。
一瞬、i7の対策版が出るまで買い控えようか迷ったけど、Haswellでもエラッタが出てたので複雑なものとしてバグは避けがたいのかも。結局欲しい時が買いどきか。
14nmはハイパフォーマンスプロセスの開発が放棄されたらしい (スコア:1)
大原考察ではそういうことらしいので、クロックを上げるとある程度から指数的に熱が増える
で、そうなっても性能が伸びないのを防ぐためにデコーダを豪華にしてパイプラインを伸ばした
で、最近のCPUは熱暴走しないよう温度を見てクロックを落とす動作をするんだけど、
FIVRのオミットで制御粒度が荒くなった。にもかかわらず熱制御は5xxxシリーズレベルでピーキーになっていて
周波数を落とすのが間に合わないか、とある重たいopコードが優先されて落とせないか、そんな感じでしょう。
高速プロセスなら問題なかったかもしれない組み合わせがSoCプロセスではダメだったと。
バリデーションの見落としですかね。
microcodeで温度制御を優先すればフルロードでも落ちないでしょうし、HTでカリカリに使わない
下位モデルでは多分落ちない。
温度制御を無効にするようなopcodeのせいだと下位でも落ちる可能性がありますけど、i7でしか確認されてないので
Tjunctionからの周波数降下が間に合ってないんでしょうか。
Re:14nmはハイパフォーマンスプロセスの開発が放棄されたらしい (スコア:2)
スレッド数と与えるパラメータも決まっていることが熱暴走説だと説明できないような……?
Re: (スコア:0)
じゃあ外から液体窒素でも何でも使ってガンガンに冷やせばフリーズしなくなる、或いはフリーズする可能性が下がるってことかなあ? やろうと思えば可能な検証方法だと思うが。
Re: (スコア:0)
大原考察ではそういうことらしいので、
大原って雄介? およそ技術的なことはなんも分かってないライターの名前は出すべきではないかと。
Re: (スコア:0)
じゃあSkylakeはクロック落とせばPrime95でフリーズしなくなんの??
Re:デッドロックでしょ (スコア:0)
マルチスレッドでフリーズといえばデッドロック。
この問題にぶち当たると、なぜ、どういうタイミングで起きるのか、全くわからないことが多い。
Re: (スコア:0)
特定のコードシーケンスで発生するならスレッド数を最大にしなくても発生しそうなものだし、リソースの競合なら「しばらく」実行しなくても発生しそうな気が。
CMOSは高温になると動作条件が厳しくなるので、CPUをフルに使うのも「複雑な処理」と言えるでしょうね。
Prime95って設定した上限温度に達するとベンチを停止する機能があって、グリスのCPUでAVXやHT有効だとどんどん温度が上がっていきました。
Prime95はそこらのベンチよりも相当負荷が高そうなベンチなので…
Re: (スコア:0)
特定のコードシーケンスで発生するならスレッド数を最大にしなくても発生しそうなものだし、リソースの競合なら「しばらく」実行しなくても発生しそうな気が。
複数のコアから利用されるリソースのシェアに完全でないところがあり確率的に不具合が発生するとかが原因なら「スレッド数最大」&「「しばらく」実行」でフリーズするというのもあることだと思うよ。