(i) プログラムが1 つの CPU クラス (例: マルチコア Core i7) でコードをコンパイルすることによって最適化されている場合、そのパフォーマンスは古い世代の他の CPU (例: Pentium 4) では最適以下のレベルになります。 .. 最適化すると、他の CPU のパフォーマンスに悪影響を与える可能性があります..?
(ii) 最適化のために、コンパイラは古い CPU では利用できない x86 拡張機能 (SSE 4 など) を使用する場合があります..それで、古い CPU の一部の非拡張ベースのルーチンへのフォールバックはありますか..?
(iii) インテル C++ コンパイラーは、Visual C++ コンパイラーまたは GCC よりも最適化されていますか..
(iv) 真にマルチコア スレッド化されたアプリケーションは、古い CPU (Pentium III または 4 など) 上で効率的に実行されますか?
プラットフォームでコンパイルすることは、このプラットフォーム用に最適化することを意味するものではありません。（多分それはあなたの質問の悪い言い回しです。）
私が使用したすべてのコンパイラーで、プラットフォームXの最適化は命令セットに影響を与えず、使用方法のみに影響します。たとえば、i7の最適化ではSSE2命令は有効になりません。
また、オプティマイザーはほとんどの場合、最適化されていないプラットフォームの「ペシミゼーション」を回避します。たとえば、i7を最適化する場合、通常、i7の小さな改善は、別の一般的なプラットフォームの大ヒットを意味する場合は選択されません。
また、命令セットのパフォーマンスの違いにも依存します。私の印象では、過去10年間でそれらははるかに少なくなっています（ただし、最近は深く掘り下げていませんが、最新の世代では間違っている可能性があります）。また、最適化によって顕著な違いが生じるのはごく一部の場所のみであることも考慮してください。
オプティマイザの可能なオプションを説明するために、switchステートメントを実装するための次のメソッドを検討してください。
if (x==c) goto label 「最良の」アルゴリズムは、比較の相対的なコストに依存し、固定オフセットでジャンプし、メモリから読み取られたアドレスにジャンプします。最近のプラットフォームではそれほど違いはありませんが、わずかな違いでも、いずれかの実装を優先する可能性があります。
おそらく、CPU X で実行するためにコードを最適化すると、CPU Y で実行するために最適化された同じコードよりも、そのコードが CPU Y で最適化されなくなります。
おそらくそうではありません。
一般化することは不可能です。コードをテストして、独自の結論に達する必要があります。
おそらくそうではありません。
一連の条件 (コンパイラの選択、CPU の選択、コンパイル用の最適化フラグの選択) の下で X が Y よりも高速であるべき理由に関するすべての議論に対して、賢明な SOer は反論を見つけ、すべての例に対して反例を見つけます。ゴムが路面に出たら、テストして測定するしかありません。コンパイラ X がコンパイラ Y よりも「優れている」かどうかを知りたい場合は、最初に「優れている」とはどういう意味かを定義し、次に多くの実験を実行してから、結果を分析します。
I）どのCPUタイプを優先するかをコンパイラーに指示しなかった場合、すべてのCPUでわずかに最適ではなくなる可能性があります。一方、特定のタイプのCPUに最適化するようにコンパイラーに通知した場合、他のCPUタイプでは間違いなく最適ではない可能性があります。
II）いいえ（少なくともIntelとMSの場合）。コンパイラにSSE4でコンパイルするように指示すると、テストせずにコード内のどこでもSSE4を使用しても安全だと感じます。プラットフォームがSSE4命令を実行できることを確認するのはあなたの責任になります。そうしないと、プログラムがクラッシュします。2つのライブラリをコンパイルして、適切なライブラリをロードすることをお勧めします。SSE4（またはその他の命令セット）用にコンパイルする代わりに、組み込み関数を使用することもできます。組み込み関数は、（わずかなオーバーヘッドを犠牲にして）最高のパフォーマンスを発揮する命令セットを内部でチェックします。ここでは、命令組み込み関数（命令セットに固有のもの）ではなく、組み込み関数について説明していることに注意してください。
III）それ自体はまったく別の議論です。バージョンごとに異なり、プログラムによって異なる場合があります。したがって、ここでの唯一の解決策はテストすることです。ただし、注意してください。Intelコンパイラは、Intel以外で実行するために適切にコンパイルされないことが知られています（たとえば、組み込み関数はAMDまたはVia CPUの命令セットを認識しない場合があります）。
IV）新しいCPUのオンダイ効率と明らかなアーキテクチャの違いを無視すると、そうです、古いCPUでも同様に機能する可能性があります。マルチコア処理自体は、CPUの種類に依存しません。ただし、パフォーマンスはマシンアーキテクチャ（例：メモリ帯域幅、NUMA、チップ間バス）、およびマルチコア通信の違い（例：キャッシュコヒーレンシ、バスロックメカニズム、共有キャッシュ）に大きく依存します。これらすべてがMPの新しいCPU効率と古いCPU効率を比較することを不可能にしますが、それはあなたが私が信じていることではありません。したがって、全体として、新しいCPU用に作成されたMPプログラムは、古いCPUのMPの側面をあまり効率的に使用してはなりません。言い換えれば、特に古いCPU用にプログラムのMPの側面を微調整するだけでは、あまり効果がありません。
(1) 可能であるだけでなく、ほとんどすべての世代の x86 プロセッサで文書化されています。8088 に戻って、すべての世代で前進してください。最新のプロセッサは、現在の主流のアプリケーションとオペレーティング システム (Linux を含む)で低速でした。32 ビットから 64 ビットへの移行は役に立ちません。コアが増えてクロック速度が低下すると、さらに悪化します。同じ理由で、これは逆方向にも当てはまります。
(2) バイナリの失敗またはクラッシュを当てにしてください。幸運に恵まれることもありますが、ほとんどの場合、そうではありません。はい、新しい命令があります。それらをサポートすることは、おそらく未定義の命令をトラップし、その命令のソフトウェアエミュレーションを行うことを意味します。最適化は新しい命令を使用できますが、それ以上に、あなたが話していると推測している最適化の大部分は、さまざまなパイプラインが停止しないように命令を並べ替えることに関係しています。x86 ファミリではコアが大きく変わりすぎるため、ある世代のプロセッサでは高速になるように調整しますが、別の世代では遅くなります。AMDは、ソフトウェアが追いついたときに最終的に高速になる新しいプロセッサを発明しようとするのではなく、同じコードをより高速に実行できるようにするため、しばらくの間はうまくいきました。amd と intel の両方が、クラッシュすることなくチップを実行し続けるために苦労しています。
(3) 一般的に、はい。たとえば、gcc はひどいコンパイラです。1 つのサイズですべてに適合するわけではありません。たとえば、gcc 4.x コードは、同じプロセッサの gcc 3.x コードよりも遅くなります (はい、これはすべて主観的なものであり、コンパイルされる特定のアプリケーションに依存します)。私が使用した社内コンパイラは、安価または無料のものよりもはるかに優れていました (ここでは x86 に限定していません)。しかし、彼らは価格の価値がありますか？それが問題です。
一般に、恐るべき新しいプログラミング言語と大量のメモリ、ストレージ、キャッシング層のために、ソフトウェア エンジニアリングのスキルは常に低い状態にあります。つまり、優れた最適化コンパイラーどころか、優れたコンパイラーを作成できるエンジニアのプールが時間とともに減少していることを意味します。これは少なくとも 10 年間続いています。そのため、社内コンパイラでさえ時間の経過とともに劣化しているか、社内ツールの代わりに従業員がオープンソース ツールに取り組んで貢献しているだけです。また、ハードウェア エンジニアが使用するツールも同じ理由で性能が低下しているため、最適化をあまり試みずに、クラッシュせずに実行したいプロセッサを使用できるようになりました。非常に多くのバグとチップのバリエーションがあるため、ほとんどのコンパイラ作業はバグを回避しています。要するに、gcc は単独でコンパイラの世界を破壊しました。
(4) 上記(2)参照。それに賭けないでください。これを実行したいオペレーティング システムは古いプロセッサにはインストールされない可能性が高いため、手間が省けます。Pentium III 用に最適化されたバイナリが Pentium 4 で遅くなったのと同じ理由で、その逆も同様です。マルチコア プロセッサで適切に動作するように記述されたコードは、同じアプリケーションをシングル コア プロセッサ用に最適化した場合よりも、シングル コア プロセッサでの実行が遅くなります。
問題の根本は、x86 命令セットがひどいことです。非常に多くのはるかに優れた命令セットが登場しており、世代ごとに高速化するためにハードウェアのトリックを必要としません。しかし、wintel マシンは 2 つの独占を生み出し、残りは市場に浸透できませんでした。私の友人は、これらの x86 マシンはマイクロコード化されているため、内部の命令セットが実際には見えないことを思い出させてくれます。恐ろしいISAが単なる解釈レイヤーであることにさらに腹を立てます. Javaを使っているようなものです。あなたが質問で概説した問題は、インテルがトップである限り続きます。代替品が独占にならない場合、私たちは、あなたが共通分母の一方または他方である Java モデルに永遠に行き詰まることになります。特定のハードウェアで共通プラットフォームをエミュレートし、