今日のコンパイラツールで並列化を強化するために採用されている技術が豊富にあるため（特にfor、Intel C ++コンパイラ、Microsoft Visual Studio 2011、その他さまざまなものを参照）、並列化が常に保証されているかどうか疑問に思いました。パフォーマンスを向上させるか、影響を与えません。
並列化がパフォーマンスに明らかに悪影響を与える場合はありますか？
インターネットですばやく検索してもあまり期待できなかったので、ここを見て、並列化がパフォーマンスに悪影響を与えるケースについての知識があるかどうか、さらには並列化が実際に問題を引き起こしたプロジェクトでの経験があるかどうかを確認することにしました。
また、自動ベクトル化のパフォーマンスにマイナスの影響があるかどうかについても興味がありますが、そうなる可能性はほとんどありません。
前もって感謝します！
自動ベクトル化は、理論的には「トラップ」に分類される可能性があります。この場合、すべての要素を適切な場所に配置するオーバーヘッドは、並列処理によって節約される時間よりも実際に大きくなります。コードの一部にかかる時間を分析するのは難しいため、コンパイラーが正しい決定を下すのは困難です。
これらのスライドの終わりに向かって、パフォーマンスを悪化させる自動ベクトル化に関するいくつかの例と統計があります。
並列化には通常、異なる処理要素間の抽象データ交換が含まれます。これは、すべての処理要素が、計算の一部を完了するために必要なすべてのデータに排他的にアクセスできるわけではないためです。これは、MPIジョブの異なるプロセス間で渡されるメッセージであるか、マルチスレッドプログラムの同期アクションである可能性があります。データの受け渡しや同期には時間がかかるため、通常は通信または同期オーバーヘッドと呼ばれます。オーバーヘッドと計算の比率に応じて、さまざまなクラスの問題があります。
通信や同期をまったく必要としない並列アルゴリズムは、自明な（または「驚異的」）並列問題と呼ばれます。このクラスの例は、レイトレーシングアプリケーションです。各ピクセルは、他のすべてのピクセルとは独立して計算できます。このクラスの問題は、使用される処理要素の数に比例してスケーリングします（キャッシュ効果のために、場合によっては超線形になります）。処理要素の数が2倍になり、計算の実行にかかる時間が2倍短くなります。
通信または同期がいくらか含まれている場合、通信/同期と計算の比率が高くなるにつれて、状況は次第に悪化します。通常、これは、処理要素の数を増やしても問題のサイズが固定されている場合に当てはまります。通常、オーバーヘッドは処理要素の数とともに増加しますが、要素あたりの計算量は減少します。
通常、妥当な使用法では、並列化（平均並列処理）により、パフォーマンスにプラスの影響があります。
しかし、場合によっては、開発者の観点から、それは悪影響を引き起こす可能性があります。
したがって、すべてを合理的に使用する必要があります。
そして、いくつかのリンク。申し訳ありませんが、それらは.NET / Microsoft固有ですが、そこに記載されている問題は同じです。
一般的な問題と落とし穴が説明されている良い本： 並列プログラミングのパターン：.NETFramework4を使用した並列パターンの理解と適用
より理論的な観点からは、NCにない問題、つまり、多項式数のプロセッサを搭載した並列コンピュータで多対数時間で決定可能な決定問題のクラスに関心があるかもしれません。
頭のてっぺんから、なんらかの形で並列化できない計算問題は考えられません。私が何度も遭遇したのは、並列化が不十分な問題です。
正しく並列化されていないプログラムは、順次バージョンよりも簡単に遅くなる可能性があります。これは、次の結果である可能性があります。
#pragma omp parallel for schedule(dynamic,k)チャンクサイズが小さい場合の場合ですk。#pragma omp criticalます。#pragma omp atomicの過度の使用。たとえば、順次の場合、より高速な通常のメモリアクセスが使用される場所を使用します。要約すると、私の意見では、本質的にシーケンシャルな問題はほとんどありませんが、実装が不十分な並列ソリューションの山があります。