導入
コンピューター プログラミングにおける最適化とは、一般に、関数の実行時間、データとプログラムが占めるスペース、または電力消費を削減する実践です。
最適化の第一のルールは、プログラムが動作し、機能仕様を満たした場合にのみ最適化を行うべきであるということです。経験によれば、これら 2 つの条件が満たされる前にコードに低レベルの最適化を適用すると、ほとんどの場合時間の無駄が発生し、コードの明瞭さとプログラムの適切な機能に悪影響を及ぼします。
「時期尚早な最適化は諸悪の根源です。 »
— ドナルド・クヌース、ダイクストラの言葉を引用
ただし、この切り詰められた引用は誤解されることがよくあります。完全版は次のとおりです。
「小さな局所的な最適化は、97% の確率で忘れるべきです。時期尚早な最適化が諸悪の根源です。 »
—ドナルド・クヌース
元の引用では、このルールはローカルの低レベルの最適化 (アセンブラでの書き換え、ループの展開など) にのみ適用されるべきであり、プロジェクトのアルゴリズムやアーキテクチャの選択に関する高レベルの最適化には適用されないことが非常に明確に示されています。それどころか、プロジェクトが大規模になるほど、これらの高レベルの最適化を実行することは、不可能ではないにしても、より困難でコストがかかります (時間、難易度、予算の点で)。
最新のコンパイラは、手動で実行すると面倒でソース コードが読みにくくなる、一定数の最適化を自動的に実行します。
非常に特殊なケースでは、ローカルの手動による最適化が必要になる場合がありますが、測定によると、多数のレジスタがあり、パイプライン効果の恩恵を受けるために効率を高めるために同一の命令をグループ化する必要がある RISC マシンでは、 Cコンパイラのオプティマイザがより多くの機能を提供することがよくあります。経験豊富なプログラマがアセンブリで作成するコードよりも効率的なコードになります (CISC マシンでは決してそうではありませんでした)。さらに、このコードは保守がはるかに簡単です。C の命令は、マシンの特性ではなく、コードのわかりやすさのみに関連付けられた順序のままであるためです。実際、現在のオプティマイザーでは、マシンの順序は、実行効率の理由から、命令は必ずしも連続した位置にある必要はありません。これにより、生成されたアセンブリ コードが特に解読不能になります。
最適化の実践
最初のアプローチ
最適化を始める前に、コードの速度を測定する方法を知っておく必要があります。これを行うには、パラメータ、できれば単純で測定可能なパラメータを選択する必要があります。これは、たとえば、特定のデータセットの処理時間、 1 秒あたりに表示される画像の数、さらには1 分あたりに処理されるリクエストの数などです。
測定パラメータが決定されたら、プログラムの各部分に費やされた時間を測定する必要があります。時間の 80% ～ 90% がコードの 10% (クリティカル ループ) の実行に費やされることも珍しくありません。数字はプロジェクトの規模と複雑さによって異なります。最適化で最大の利益を得るには、コードの 10% をローカライズする必要があります。このローカリゼーション手順は、プロファイラーと呼ばれる特殊なコード計測ツールを使用して実行できます。これらは、各関数の実行数と、実行中の対応するマイクロプロセッササイクルをカウントする責任があります。
次に、最も多くのリソースを消費するセクションを必要なだけ繰り返します。
- コードの一部の最適化
- パフォーマンスの向上の測定
2 番目のアプローチ
プログラムはいくつかのレベルで最適化できます。
- アルゴリズムレベルでは、(数学的な意味で) より複雑性の低いアルゴリズムと適切なデータ構造を選択することで、
- 開発言語レベルでは、可能な限り最適な命令を並べ、利用可能なライブラリを使用することで、
- 低レベル言語(C 言語、または最も重要なニーズの場合はアセンブリ言語) をローカルで使用します。
レベルの可能性を使い果たした場合にのみ、次の最適化レベルに移行します。速度を上げるためにプロジェクト全体で低レベル言語を使用することは、産業プロジェクトが犯す可能性のある最も一般的でコストのかかる間違いの 1 つです。
コードの最適化は、多くのアマチュア開発者にとって、やや魔法のような技術であると考えられており、このため、プログラミングの最もエキサイティングな部分の 1 つであると考えられています。このため、優れたプログラマとはプログラムを最初から最適化する人であると信じ込まされてしまいます。ただし、経験上、初期設計の貧弱さを補うことはできないことがわかっています。開発者の経験が最も大きく影響するのは設計です。さらに、多くの場合、そしてますます多くの場合、「優れたプログラマ」とは、賢いコードを書く人ではなく（オプティマイザの方がほとんどの場合、彼よりも優れたコードを作成します）、読みやすく使いやすいコードを書く人です。維持する。
データ構造技術やアルゴリズムに関する十分な知識は (アルゴリズムの複雑さに関する高度な理論的考察まで行かなくても) アセンブリ言語の知識よりもはるかに有益です。最適なアルゴリズムが決定したら、次のパスを使用して最も効率的な最適化を行うことができます。
- 高級言語( Schemeや Common Lisp など) で重要なコードを作成する
- リソース消費を削減しながらプログラム仕様を維持する連続的な数学的変換の適用、
- 変換されたコードを低水準言語 (C 言語) に翻訳します。
実際には、現在のマシンのパフォーマンスは、入出力が遅いアプリケーションがこれら 3 つの手順を回避し、 Haskellのような言語で直接作成できることを意味します。 Usenet フォーラムで公開された画像を体系的に収集するよく知られたngetアプリケーションは、最初の実装では Haskell で書かれていました。 C バージョンは単なる翻訳であり、このタイプのアプリケーションにとってより効率的であるとは証明されていません。一方、主に CPU とメモリ速度によって制限されるアプリケーションは、C や C++ などの言語で作成すると大きなメリットが得られます。
