フロップカウントによるアルゴリズム分析は時代遅れですか？

私の数値解析コースでは、問題のサイズに対して、必要な浮動小数点演算（フロップ）の数を数えることにより、アルゴリズムの効率を分析することを学びました。たとえば、数値線形代数に関するTrefethen＆Bauのテキストには、フロップカウントの3Dに見える写真さえあります。

キャッシュにないものをフェッチするためのメモリレイテンシは、フロップのコストよりもはるかに大きいため、「フロップは無料」と言うのが流行しています。しかし、少なくとも数値解析コースでは、フロップを数えることを生徒に教えています。代わりに、メモリアクセスをカウントするように教える必要がありますか？新しい教科書を書く必要がありますか？または、メモリアクセスがマシン固有であり、時間を費やすことができませんか？フロップまたはメモリアクセスがボトルネックであるかどうかに関して、長期的な傾向はどうなりますか？

注：以下の回答のいくつかは、「実装を強烈に書き換えて、数フロップを節約するか、キャッシュのパフォーマンスを向上させるべきですか？」しかし、私が求めているのは、「算術演算またはメモリアクセスの観点からアルゴリズムの複雑さを推定する方が便利ですか？」という行に沿ったものです。

$\beta$$F_{\mathrm{max}}$$B_{\mathrm{max}}$$\frac{F_{\mathrm{max}}}{\beta} > B_{\mathrm{max}}$$B_{\mathrm{max}}\beta > F_{\mathrm{max}}$

メモリアクセスのカウントは必須だと思いますが、次のことも考慮する必要があります。

• 必要なローカルメモリの量

• 並行性の可能性

その後、最新のハードウェアのアルゴリズムの分析を開始できます。

$O(N^4)$$O(N)$$O(N \log N)$$O(N^2)$

より広い観点から、アルゴリズムのパフォーマンスの分析は「包括的」でなければならないと思います。実際のHPC開発者およびユーザーになるように人々に教える場合、彼らは現実世界でのプログラミングのコストを理解する必要があります。私たちが持っている抽象的な分析モデルは、プログラマーの時間を考慮していません。フロップカウントとアルゴリズムの効率だけでなく、「解決までの合計時間」の観点から考える必要があります。数百万の計算を実行することを計画している場合を除き、ジョブあたり1秒のコンピューター時間を節約するルーチンを書き換えるために3〜4日プログラマーを費やすことはほとんど意味がありません。同様に、1〜2時間の計算時間を節約するための数日間の投資は、すぐに報われます。その新しいアルゴリズムは素晴らしいかもしれませんが、

他の人が指摘したように、答えはもちろんボトルネックがCPU帯域幅かメモリ帯域幅かによって異なります。任意のサイズのデータ​​セットで機能する多くのアルゴリズムでは、データセットがCPUキャッシュに収まらないため、ボトルネックは通常メモリ帯域幅です。

さらに、Knuthは、メモリアクセス分析は、おそらく最新のCPUパイプラインと分岐予測の複雑さに比べて（キャッシュへの配慮を考慮した場合でも）比較的単純であるため、時の試練に耐える可能性が高いと述べています。

Knuthは、BDDを分析する際にTAOCPのVolume 4Aで用語gigamemsを使用します。彼が以前のボリュームでそれを使用しているかどうかはわかりません。彼は、2010年の年次クリスマスツリーレクチャーで時の試練に耐えることについて前述のコメントをしました。

興味深いことに、あなたは間違ったことをやっているメモリの操作に基づいても、分析のパフォーマンスデータがすべて一度に物理RAMに収まらない場合には遊びに来て、このようなVM圧力などの要素がある簡単なよう常にではないことを示しています。

アルゴリズムのコストをどのように決定するかは、使用する科学計算の「レベル」と、検討する問題の（狭いまたは広い）クラスに依存します。

キャッシュの最適化について考える場合、これは明らかに、たとえばBLASや類似のライブラリのような数値線形代数パッケージの実装により関連しています。したがって、これは低レベルの最適化に属し、特定の問題に対する固定アルゴリズムがあり、入力に十分な制約がある場合は問題ありません。たとえば、行列が十分にスパースであると約束されている場合、共役勾配反復の高速実装にキャッシュ最適化が関連する場合があります。

一方、問題のクラスが広ければ広いほど、実際のコンピューティングで予測できることは少なくなります（たとえば、CG実装の入力行列が実際にどの程度まばらになるかわからないなど）。プログラムが実行されるはずのマシンのクラスが広いほど、キャッシュアーキテクチャを予測できなくなります。

さらに、高レベルの科学計算では、問題の構造を変更する方が適切かもしれません。たとえば、線形連立方程式の適切な前提条件を見つけることに時間を費やす場合、この種の最適化は通常、反復回数が大幅に削減されるため、低レベルの最適化よりも優れています。

結論として、キャッシュの最適化は、並列性とFLOPの漸近数の削減によって最適化するものが残っていない場合にのみ役立ちます。

理論的なコンピューターサイエンスの姿勢を適応させることは賢明だと思います。最終的に、アルゴリズムの漸近的複雑さを改善することは、既存のコード行の微最適化よりも多くの利益をもたらします。したがって、FLOPのカウントが依然として優先されます。

私はいつも、フロップ、メモリアクセス、またはあなたが持っているものを数えることについて考えることさえ拒否しました。それは1960年代のコンセプトで、あなたがやったことはほとんど与えられていましたが、アルゴリズムの最適化まではあなたがやったことだけでした。Jacobi反復のガウス消去法を使用して、均一なxyzメッシュで有限要素問題を解くことを考えてください。

これで、これを最適化して数フロップを節約し、実行時間を10％増やすことができます。または、マルチグリッドメソッドと最適なブロック前提条件を実装して、実行時に10倍にすることを検討できます。これは、生徒が行うように訓練する必要があるものです。より複雑な外部アルゴリズムが、より良い内部アルゴリズムを見つけようとするときに得られるものを考えてください。上司（キーズ）には、MHD計算の進捗状況に関するこれらのスライドがあり、この点をかなり明確にしています。

はい、廃止されました。フロップやその他の方法によるアルゴリズム分析は、問題の規模を考慮するときに、マシンの抽象的なモデルと同じくらい有用です。実際のパフォーマンスは実装とハードウェアの両方に依存し、後者の抽象モデルの現実への適用性は時間とともに低下しています。たとえば、分子動力学などの複雑なアルゴリズムの実装をさらに並列化すると、さまざまな側面がさまざまなハードウェアでレート制限になり、アルゴリズム分析は観測とは関係ありません。ある意味では、唯一の重要なことは、問題のハードウェアタイプでのアルゴリズムの実装のパフォーマンスを測定することです。

そのような抽象化は学習ツールとして有用ですか？はい、教育に使用される多くのモデルのように、それらはモデルの制限の理解と並んで配置されている限り有用です。古典的な力学は、小さな距離や大きな速度のスケールでは機能しないことを理解している限りは問題ありません...

質問に実際に答えているわけではありませんが、考慮すべき別の変数をさらに追加します。考慮すべきことは、プログラミング言語の機能です。たとえば、Python sortは、他の優れたプロパティの中でも特に設計されているTimsortアルゴリズムを使用して、比較の数を最小限に抑えます。これは、Pythonオブジェクトでは遅くなる可能性があります。一方、C ++での2つのフロートの比較は非常に高速ですが、それらのスワップはよりコストがかかるため、他のアルゴリズムを使用します。

他の例としては、動的メモリ割り当て（Pythonリストでは簡単、実行時と開発者の両方の時間で高速.append()）、対FORTRANまたはCがあります。参照Pythonは速くFORTRANを超えています。