アカウント名:
パスワード:
命令デコーダかL1命令キャッシュ、あるいはRyzenで新設されたμOPキャッシュ辺りに問題がある可能性が高く、Twitterではマイクロコードの更新で直るのか疑問視する意見もあった。
マイクロコードか設定でキャッシュを無効化する対策がされるだろうから、修正できるでしょ。#あれ、なんか既視感 [wikipedia.org]がある話の気が
タレコミのリンク先を見てると、分岐予測で何かコケてる気がするんですけどね。http://www.4gamer.net/games/300/G030061/20170228119/ [4gamer.net]分岐予測で、積極的にニューラルネットワークを使ってるので、そこのアルゴリズムのバグが絡んでるんじゃないかという臭いがプンプンしますけどね。変なアドレスに飛ばすとか、キャッシュページ間違えるとか、分岐予測の結果を出すときか外した時に間違ったアドレスを振り出してるような…
となると、マイクロコードかもしれないし、ハードコーディングされてるかもしれない(;´Д`)
もう一つありました。「分岐予測しなくていいのに発動してしまう」。非常にレアケースということで、ブランチ命令でもないのに分岐予測を呼び出して、その結果、おかしなアドレスを振り出して分岐判断しちゃうとか…# JMPとかCALLで起こってるのだとしたら、尚更…
お前、正しい動作と単に(すごく)遅いのことの区別もついていないのかよ……
分岐予測ってのは、分岐の両方が正常に動作するコードである必要はあるんだよ。食レポを求められているが、ケーキと煎餅のどっちの感想が欲しいか未確定なのが分岐予測。両方食ってみて片方が毒饅頭だとそのままレビュアーは死ぬ。
分岐予測と投機実行を混同してない?
分岐予測は間違っても速度が遅いメモリへのアクセスが発生するだけ
投機実行は分岐する場合/しない場合の両方で計算結果正しい必要がある
#但し、Rizen は投機実行するアーキなのは知られているので、そもそも遅くなるとか馬鹿じゃないかとしか思えないけど。
現代のアークテクチャは分岐多段で複数のストリームで投機実行をかけますが、ここでは話を簡単にするために一方向の分岐で考えましょう。 命令実行時、デコーダで分岐命令が検知された場合は、分岐先を登記実行するわけですけど、その際にそのストリームについているタグとして、普通は当該分岐命令で分岐したかしないかが必ず含まれます。 また、分岐先アドレスと分岐先フェッチに使うアドレスは別のゲートですから、同じであるという保証なんかどこにもないです。今そういうレベルの話をしている。 で、実際に分岐判定が下ったとき、どのストリームを選択するかの判定をしなければいけないわけですが、この際にストリームの判定をするのに使うのも、当該分岐命令で分岐したかしないかで、いまはその分岐命令の判定時のフラグ判定が化けたか、あるいは分岐先アドレスのフェッチが化けたか、っていっているわけですから、プロセッサ実行時にそれが検知できるわけがないし、実行結果も正しくない。
このCPUは知らないけど、一般的なCPUでは分岐する時には既に予測に従って実行(投機実行)されてるんだよ予測先が間違ってれば、既に実行されている結果も間違ってるわけで
どこにぶら下げるか迷ったんですが、ここに。なんかね、言葉の定義の問題ですれ違ってるだけで、それを説明しないといつまで経っても平行線でしょう。
・狭義の(本来の)「分岐予測」 条件分岐命令で、「分岐する場合と分岐しない場合と、どちらが確率が高いか」を判定するもの。分岐予測器の出力に基づいて、分岐する可能性が高いなら分岐先の命令を投機実行するし、分岐しない可能性が高いなら続く命令を投機実行するだけ。 その後、実際の条件判定結果に基づいて、当たっていればそのまま実行継続するし、外れたなら既に実行された結果を差し戻す。 分岐予測には「予測先」なんて概念はありません。分岐予測が「分岐する」と判定した時に投機実行するのは、「実際の分岐命令の分岐先」であり、「予測」ではありません。だから、「分岐予測を間違えても遅くなるだけで結果はおかしくならない」です。
・狭義の分岐予測とは異なる「分岐先予測」分岐予測とは別に「分岐先予測」という技術もあります。「分岐するかどうか」ではなく、「分岐先がどこになるか」を予測することで、分岐先命令のフェッチ待ち時間によるオーバーヘッドを減らす技術
・広義の(CPU構成要素としての)「分岐予測ユニット」Ryzenの「分岐予測ユニット」は、分岐予測と分岐先予測とμOpキャッシュとが一体になっていて、予測に基づいて実行すべきμOpコードを直接出力します。ここが間違えたら、まったく異なる命令を実行してしまう可能性があります。
この「狭義の分岐予測」と「分岐予測ユニット」のどちらについて語るのかを明確にせずに議論してるからすれ違ってる感じですね。
予測先が間違ってれば、既に実行されている結果も間違ってるわけで
そのどっちが正しいかという予測が間違ってるんじゃなく、予測先が実行できないような変なところを指してるから問題になってる。
上のコメントにも出てたけど、CPUはケーキか煎餅どちらか予測していていつもは、ああケーキだね、こんどは煎餅だねってなるんだけど、
今回の件は、ケーキだと予測したけど本当は煎餅だったね、てへ☆彡って話じゃなく、ごく希に片方が毒饅頭にかわるからヤベェって話だよ
taka2氏が言ってるのは、Ryzenの設計上は一体化しているけども、理論的にはケーキと毒饅頭を持ってくるまでが分岐予測で、食うのは投機実行という別の機構だっていう話。
ACさんが言ってる"遅くなるだけ"というのは、投機実行やキャッシュ機構にバグがなければ、毒饅頭はそのまま捨てられてキャッシュメモリ帯域や容量が無駄になるだけ、全体的に遅くなるだけだということ。
alp氏が"分岐予測 Hitで違うストリームを食わされる"と言っているのは、「(分岐予測バグによって)投機実行機構に間違ったopが実際に渡されれば」ということ。
だもんで「すれ違ってる」と言ってる。
すみません、直下にぶら下がってないのでコメントに気づいてませんでした。
ケーキと煎餅の例で言うならば、・(狭義の)分岐予測: どちらの注文が入るか確定していない状況で、どちらを注文する確率が高いか予想する部分。・投機実行: 予測に基づいて調理を始める。予測が当たれば出来たをものそのまま提供。外れたら作りかけのものは捨てて、注文通りのものを調理する。・(広義の)分岐予測: 狭義の分岐予測に基づいて厨房にオーダーを出すところまでひっくるめた大枠。と考えるべきでしょう。
> 理論的にはケーキと毒饅頭を持ってくるまでが分岐予測
違います。「(狭義の)分岐予測」はあくまで「ケーキか煎餅かを予測」するところまで。分岐予測が間違えても注文処理に時間がかかる(遅くなる)だけ。「煎餅が来るはずなのに毒饅頭が出てきた」としたら、それは「(狭義の)分岐予測は煎餅と予想した」が、「厨房が毒饅頭を作ってきた」という状況。で、「実際の注文は煎餅だった(予測が当たった)ので、できたものをそのまま客に出す」ことにした場合、その結果は「客に毒饅頭を食わせる」ことになります。
これは、「狭義の分岐予測」には問題はないが、予測に基づいた厨房処理のどこかに問題ある状況であり、それをひっくるめた全体の「広義の分岐予測」には問題がある状態。
たとえを止めて普通に書くと、「(広義の)分岐予測」=「(狭義の)分岐予測」+「分岐先予測」+「分岐予測・分岐先予測の結果に基づいた命令フェッチ」という処理構成において、「分岐予測に基づいた『命令フェッチ処理』がおかしい」と推測される状況で、あるAC氏他は「それは『(狭義の)分岐予測』の問題ではない」と主張していますし、alp氏他は「それは『(広義の)分岐予測』の問題である」と主張しているわけですが、これは分岐予測の定義がずれてるだけで、どちらが間違っているとかいう話ではないでしょう。
「分岐予測」がどのような処理なのか知っていたら決して出てこないような煽り文句ですね…。
予測が外れたことを正確に把握できれば本来と違うものは出力されないのだが。例えば予測が外れたのに予測があたったと勘違いして実行を継続すればそりゃその後の処理が狂うだろう。また予測の成否は把握したが本来渡す処理ではなく別の処理を渡した場合も狂うだろう。#RyzenユーザでもないAMD社員でもない小売店でもない第三者からすりゃこの手の論議は楽しいな
>あのさあ、お前らバカだろ>分岐予測は予測でしかないから、本来とは違うものが出力されても遅くなるだけでプログラムは正しく実行されるんだよ何度見てもこの返答はないなあ今日日のCPU知ってて予測でしか無いなんて絶対出てこない言葉だしそういう知りもしない事を知った風に言って、他人を馬鹿にまでしてるなんて単なる荒らしじゃないか
言い方悪いけど> 分岐予測は予測でしかないから、本来とは違うものが出力されても遅くなるだけでプログラムは正しく実行されるんだよは正しい
分岐予測は、当たるか、外れるか、で結果は2通りしかない
分岐予測が当たった場合はパイプラインが滞りなく処理され何も問題ない分岐予測が外れた場合はパイプラインを一度リセットするので処理が遅くなるだけで何も問題ない
それは分岐予測が正常に機能している場合ですよね。
馬鹿発見!
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常
AMDではまれによくある事 (スコア:1)
マイクロコードか設定でキャッシュを無効化する対策がされるだろうから、修正できるでしょ。
#あれ、なんか既視感 [wikipedia.org]がある話の気が
Re:AMDではまれによくある事 (スコア:2)
タレコミのリンク先を見てると、分岐予測で何かコケてる気がするんですけどね。
http://www.4gamer.net/games/300/G030061/20170228119/ [4gamer.net]
分岐予測で、積極的にニューラルネットワークを使ってるので、そこのアルゴリズムのバグが絡んでるんじゃないかという臭いがプンプンしますけどね。変なアドレスに飛ばすとか、キャッシュページ間違えるとか、分岐予測の結果を出すときか外した時に間違ったアドレスを振り出してるような…
となると、マイクロコードかもしれないし、ハードコーディングされてるかもしれない(;´Д`)
Re:AMDではまれによくある事 (スコア:2)
もう一つありました。
「分岐予測しなくていいのに発動してしまう」。
非常にレアケースということで、ブランチ命令でもないのに分岐予測を呼び出して、その結果、おかしなアドレスを振り出して分岐判断しちゃうとか…
# JMPとかCALLで起こってるのだとしたら、尚更…
Re:AMDではまれによくある事 (スコア:1)
石によって頻度がばらつくようですし、リンク手繰るような分岐では出なくて、分岐で処理を大きく変える処理が多いようなアプリで出ているっぽい。
Re:AMDではまれによくある事 (スコア:1)
分岐予測は予測でしかないから、本来とは違うものが出力されても遅くなるだけでプログラムは正しく実行されるんだよ
Re: (スコア:0)
Re: (スコア:0)
お前、正しい動作と単に(すごく)遅いのことの区別もついていないのかよ……
Re: (スコア:0)
分岐予測ってのは、分岐の両方が正常に動作するコードである必要はあるんだよ。
食レポを求められているが、ケーキと煎餅のどっちの感想が欲しいか未確定なのが分岐予測。
両方食ってみて片方が毒饅頭だとそのままレビュアーは死ぬ。
Re: (スコア:0)
分岐予測と投機実行を混同してない?
分岐予測は間違っても
速度が遅いメモリへのアクセスが発生するだけ
投機実行は
分岐する場合/しない場合の両方で
計算結果
正しい必要がある
Re:AMDではまれによくある事 (スコア:1)
#但し、Rizen は投機実行するアーキなのは知られているので、そもそも遅くなるとか馬鹿じゃないかとしか思えないけど。
Re: (スコア:0)
仮に実行するというのは、計算結果をバッファにため込んで一切の副作用は起きない
分岐予測が正しいと分かった時点で、バッファを吐き出して状態に反映する
予測が間違っていたら、バッファを破棄して分岐命令から(新しい投機)実行を続ける
分岐予測はする・しないの1ビットの判断しかなくて、分岐先アドレスの計算は予測ではなくて確定的に計算できるから、ここれが壊れたら正しくないパスを予測するようになる
そうなれば間違ったパスを仮実行しがちになって、仮実行の結果がバンバン破棄されて遅くはなるけど、動作がめちゃくちゃになることはない
alpさんもさ、
> 分岐予測はその本来の目的からしてかならず分岐先の命令をプリフェッチするので、それが狂ったら投機実行などやっていなくても動作はめちゃめちゃになる。
と言い張るんなら、俺が書いたのと同程度には詳しいメカニズムを書いてごらんよ
Re:AMDではまれによくある事 (スコア:1)
現代のアークテクチャは分岐多段で複数のストリームで投機実行をかけますが、ここでは話を簡単にするために一方向の分岐で考えましょう。
命令実行時、デコーダで分岐命令が検知された場合は、分岐先を登記実行するわけですけど、その際にそのストリームについているタグとして、普通は当該分岐命令で分岐したかしないかが必ず含まれます。
また、分岐先アドレスと分岐先フェッチに使うアドレスは別のゲートですから、同じであるという保証なんかどこにもないです。今そういうレベルの話をしている。
で、実際に分岐判定が下ったとき、どのストリームを選択するかの判定をしなければいけないわけですが、この際にストリームの判定をするのに使うのも、当該分岐命令で分岐したかしないかで、いまはその分岐命令の判定時のフラグ判定が化けたか、あるいは分岐先アドレスのフェッチが化けたか、っていっているわけですから、プロセッサ実行時にそれが検知できるわけがないし、実行結果も正しくない。
Re: (スコア:0)
> いまはその分岐命令の判定時のフラグ判定が化けたか、
分岐条件が化けた、ってことですね
分岐予測関係ないじゃん
> あるいは分岐先アドレスのフェッチが化けたか
命令フェッチアドレスが化けた、ってことですね
分岐予測関係ないじゃん
で、他の説よりもあなたの説がよりもっともらしい、というのは示せますか?
ryzenの問題はランダムとは言い切れないようですが
Re: (スコア:0)
このCPUは知らないけど、一般的なCPUでは分岐する時には既に予測に従って実行(投機実行)されてるんだよ
予測先が間違ってれば、既に実行されている結果も間違ってるわけで
Re:AMDではまれによくある事 (スコア:2)
どこにぶら下げるか迷ったんですが、ここに。
なんかね、言葉の定義の問題ですれ違ってるだけで、それを説明しないといつまで経っても平行線でしょう。
・狭義の(本来の)「分岐予測」
条件分岐命令で、「分岐する場合と分岐しない場合と、どちらが確率が高いか」を判定するもの。分岐予測器の出力に基づいて、分岐する可能性が高いなら分岐先の命令を投機実行するし、分岐しない可能性が高いなら続く命令を投機実行するだけ。
その後、実際の条件判定結果に基づいて、当たっていればそのまま実行継続するし、外れたなら既に実行された結果を差し戻す。
分岐予測には「予測先」なんて概念はありません。分岐予測が「分岐する」と判定した時に投機実行するのは、「実際の分岐命令の分岐先」であり、「予測」ではありません。だから、「分岐予測を間違えても遅くなるだけで結果はおかしくならない」です。
・狭義の分岐予測とは異なる「分岐先予測」
分岐予測とは別に「分岐先予測」という技術もあります。「分岐するかどうか」ではなく、「分岐先がどこになるか」を予測することで、分岐先命令のフェッチ待ち時間によるオーバーヘッドを減らす技術
・広義の(CPU構成要素としての)「分岐予測ユニット」
Ryzenの「分岐予測ユニット」は、分岐予測と分岐先予測とμOpキャッシュとが一体になっていて、
予測に基づいて実行すべきμOpコードを直接出力します。
ここが間違えたら、まったく異なる命令を実行してしまう可能性があります。
この「狭義の分岐予測」と「分岐予測ユニット」のどちらについて語るのかを明確にせずに議論してるからすれ違ってる感じですね。
Re:AMDではまれによくある事 (スコア:1)
予測先が間違ってれば、既に実行されている結果も間違ってるわけで
そのどっちが正しいかという予測が間違ってるんじゃなく、予測先が実行できないような変なところを指してるから問題になってる。
上のコメントにも出てたけど、CPUはケーキか煎餅どちらか予測していて
いつもは、ああケーキだね、こんどは煎餅だねってなるんだけど、
今回の件は、ケーキだと予測したけど本当は煎餅だったね、てへ☆彡って話じゃなく、
ごく希に片方が毒饅頭にかわるからヤベェって話だよ
Re: (スコア:0)
taka2氏が言ってるのは、Ryzenの設計上は一体化しているけども、理論的にはケーキと毒饅頭を持ってくるまでが分岐予測で、食うのは投機実行という別の機構だっていう話。
ACさんが言ってる"遅くなるだけ"というのは、投機実行やキャッシュ機構にバグがなければ、毒饅頭はそのまま捨てられてキャッシュメモリ帯域や容量が無駄になるだけ、全体的に遅くなるだけだということ。
alp氏が"分岐予測 Hitで違うストリームを食わされる"と言っているのは、「(分岐予測バグによって)投機実行機構に間違ったopが実際に渡されれば」ということ。
だもんで「すれ違ってる」と言ってる。
Re:AMDではまれによくある事 (スコア:1)
これは間違い。分岐予測の誤動作ってのは、分岐予測ミスなら上記の通りですけど、分岐予測 Hit の場合、要するに判定として分岐方向を間違うということだから、全体に遅くなるだけなんて程度ですむ訳がない。
Re:AMDではまれによくある事 (スコア:1)
すみません、直下にぶら下がってないのでコメントに気づいてませんでした。
ケーキと煎餅の例で言うならば、
・(狭義の)分岐予測: どちらの注文が入るか確定していない状況で、どちらを注文する確率が高いか予想する部分。
・投機実行: 予測に基づいて調理を始める。予測が当たれば出来たをものそのまま提供。外れたら作りかけのものは捨てて、注文通りのものを調理する。
・(広義の)分岐予測: 狭義の分岐予測に基づいて厨房にオーダーを出すところまでひっくるめた大枠。
と考えるべきでしょう。
> 理論的にはケーキと毒饅頭を持ってくるまでが分岐予測
違います。「(狭義の)分岐予測」はあくまで「ケーキか煎餅かを予測」するところまで。分岐予測が間違えても注文処理に時間がかかる(遅くなる)だけ。
「煎餅が来るはずなのに毒饅頭が出てきた」としたら、それは「(狭義の)分岐予測は煎餅と予想した」が、「厨房が毒饅頭を作ってきた」という状況。
で、「実際の注文は煎餅だった(予測が当たった)ので、できたものをそのまま客に出す」ことにした場合、その結果は「客に毒饅頭を食わせる」ことになります。
これは、「狭義の分岐予測」には問題はないが、予測に基づいた厨房処理のどこかに問題ある状況であり、
それをひっくるめた全体の「広義の分岐予測」には問題がある状態。
たとえを止めて普通に書くと、
「(広義の)分岐予測」=「(狭義の)分岐予測」+「分岐先予測」+「分岐予測・分岐先予測の結果に基づいた命令フェッチ」
という処理構成において、「分岐予測に基づいた『命令フェッチ処理』がおかしい」と推測される状況で、
あるAC氏他は「それは『(狭義の)分岐予測』の問題ではない」と主張していますし、
alp氏他は「それは『(広義の)分岐予測』の問題である」と主張しているわけですが、
これは分岐予測の定義がずれてるだけで、どちらが間違っているとかいう話ではないでしょう。
Re: (スコア:0)
分岐予測があってもなくても、それとは別に分岐先を確定するユニットを必ず備えている
分岐先を確定するのは、CPUのなかにはそのユニットしかない
ブロック図を見ればALUとかLoad/StoreとならんでBranch Unitがあるでしょ、それ
alpさんの言っているのは実はBranch Unitのことだから、実は分岐予測とは関係がない話
Re: (スコア:0)
「分岐予測」がどのような処理なのか知っていたら決して出てこないような煽り文句ですね…。
Re: (スコア:0)
予測が外れたことを正確に把握できれば本来と違うものは出力されないのだが。
例えば予測が外れたのに予測があたったと勘違いして実行を継続すればそりゃその後の処理が狂うだろう。
また予測の成否は把握したが本来渡す処理ではなく別の処理を渡した場合も狂うだろう。
#RyzenユーザでもないAMD社員でもない小売店でもない第三者からすりゃこの手の論議は楽しいな
Re: (スコア:0)
>あのさあ、お前らバカだろ
>分岐予測は予測でしかないから、本来とは違うものが出力されても遅くなるだけでプログラムは正しく実行されるんだよ
何度見てもこの返答はないなあ
今日日のCPU知ってて予測でしか無いなんて絶対出てこない言葉だし
そういう知りもしない事を知った風に言って、他人を馬鹿にまでしてるなんて単なる荒らしじゃないか
Re: (スコア:0)
言い方悪いけど
> 分岐予測は予測でしかないから、本来とは違うものが出力されても遅くなるだけでプログラムは正しく実行されるんだよ
は正しい
分岐予測は、当たるか、外れるか、で結果は2通りしかない
分岐予測が当たった場合はパイプラインが滞りなく処理され何も問題ない
分岐予測が外れた場合はパイプラインを一度リセットするので処理が遅くなるだけで何も問題ない
Re: (スコア:0)
それは分岐予測が正常に機能している場合ですよね。
Re: (スコア:0)
馬鹿発見!