問題タブ [speculative-execution]

私が理解しているように、CPUが投機的にコードを実行すると、投機的な分岐に切り替える前にレジスタの状態を「バックアップ」するため、予測が間違っている場合(分岐を役に立たなくする)-レジスタの状態は次のようになります「状態」を損なうことなく、安全に復元されます。

それで、私の質問は次のとおりです。投機的に実行された CPU ブランチに、RAM にアクセスするオペコードを含めることができますか?

つまり、RAM へのアクセスは「アトミック」操作ではありません。データが現在 CPU キャッシュにない場合、メモリからの 1 つの単純なオペコード読み取りで実際の RAM アクセスが発生する可能性があり、非常に時間のかかる操作になる可能性があります。 、CPU の観点から。

そして、そのようなアクセスが実際に投機的ブランチで許可されている場合、それは読み取り操作のみですか? なぜなら、ブランチが破棄されて「ロールバック」が実行された場合、そのサイズに応じて、書き込み操作を元に戻すことは非常に遅く、扱いにくいものになる可能性があるとしか思えないからです。そして、確かに、一部の CPU ではレジスタ自体が CPU キャッシュ上に物理的に配置されているため、少なくともある程度は読み取り/書き込み操作がサポートされています。

したがって、おそらくより正確な定式化は次のようになります。投機的に実行されるコード片の制限は何ですか?

HDFS の特定の場所にデータを書き込む投機 (spark.speculation=true) が有効になっている Spark 2.x アプリケーションがあるとします。

タスク (HDFS にデータを書き込む) に時間がかかる場合、Spark は別のエグゼキューターに同じタスクのコピーを作成し、両方のジョブが並行して実行されます。

Spark はこれをどのように処理しますか? 明らかに、両方のタスクが同時に同じファイルの場所にデータを書き込もうとするべきではありません (この場合は発生しているようです)。

どんな助けでも大歓迎です。

ありがとう