1. 序章

このチュートリアルでは、パフォーマンスメトリックが時間である場合の改善率を計算する方法を説明します。たとえば、コードをより高速に実行するように最適化し、新しいバージョンを比較するときに、このようなメトリックに関心がある場合があります。古いもののパフォーマンスに。

このような経験的アプローチは、最悪の場合と平均的な場合の複雑さのより厳密な数学的分析を補完します。 さらに、コードが複雑すぎて複雑さの分析と比較ができない場合は、経験的評価が唯一の選択肢です。 その場合、結論を正当化するために、おそらくいくつかの統計を使用する必要があります。

2. What Is a Time Improvement?

これが、新しいバージョンのコードがいくつかのタスクを実行するのにかかる時間であり、前のバージョンがかかる時間であるとしましょう。 私たちの目標は、パーセンテージよりもどれだけ優れているかを定量化することです。

時間を比較する場合、数値は小さい方が良いですが、人々は直感的に少量をパフォーマンスの低下と関連付けます。したがって、反転するメトリックが必要です。そうすると、新しいバージョンにより大きなスコアが割り当てられます。

また、スコアは絶対的な用語ではなく、相対的な用語で改善を表現する必要があります。 なんで? ほとんどの人は、期間を1000秒から900秒に短縮しても、200秒から100秒に短縮するほど大きな改善にはならないことに同意するでしょう。 パーセンテージは、そのような違いを効果的に伝えるのに役立ちます。

両方の目標を達成するには、基本的に2つの方法があります。

3. 時間の節約としての改善

まず、の改善は、以前と同じタスクを完了するために必要な時間の短縮であると言えます。そこで、最初にとの違いを見つけ、次にそれを:で除算します。

(1)  

たとえば、ニューラルネットワークをトレーニングするための新しいアルゴリズムを設計しているとしましょう。 それをテストするために、ネットワークをいくつかのデータに適合させます。 アルゴリズムは、ネットワークをトレーニングするのに300秒かかりました。 私たちはより良いことをしようとしているので、いくつかの巧妙な最適化の後、トレーニング時間を30秒に短縮します。 上記の式を使用すると、90%が得られます。

   

3.1. 解釈

このように定義すると、改善により、新しいバージョンに切り替えることで古いバージョンの実行時間の何分の1を節約できるかがわかります。の場合、スコア( 1 )は正であり、私たちは実際に時間を節約するので意味があります。 対照的に、の場合、負のパーセンテージが得られます。 これは、古いバージョンの方が優れていることを示すものと解釈されますが、負のパーセンテージはほとんどの人にとってそれほど直感的ではありません。

4. 新しい作業量としての改善

改善率を計算する別の方法は、古いバージョンが作業単位(タスクなど)を完了するのにかかった時間と同じ時間で、新しいバージョンで実行できる作業量を尋ねることです

したがって、古いバージョンが1ユニットを完了するのに数秒かかり、新しいバージョンが1ユニットの作業を数秒で完了する場合、次のようになります。

(2)  

私たちが尋ねたことを正確に教えてくれます。 の場合、100%を超える数値が得られます。これは、直感と一致します。 逆に、の場合、1未満の数値が得られます。これは、新しいバージョンの動作が遅くなることを意味します。

4.1. 例

上記と同じ実行時間を使用すると、次のようになります。

   

したがって、古いバージョンが1つだけを完了するのと同じ時間で、新しいバージョンで10単位の作業を完了することができます。

4.2. 変化

このアプローチのバリエーションは次のとおりです。

(3)  

唯一の違いは、式( 2 )を使用して得られた結果から100% fromを引くことです。 それは解釈をわずかに変えます。 ここで、スコアは、古いバージョンが作業ユニットを完了するまでに新しいバージョンが完了することができる追加のユニット数を示します。

ただし、の場合、負のパーセンテージが得られます。これは直感的ではありません。 さらに、スコアが0%から100%の場合、古いコードと比較して、新しいバージョンの方が高速ですが、追加の作業単位が1つ未満であることを意味します。

5. 改善の統計的評価

統計的に言えば、単一の実行を比較することによって、2つのバージョンのコードの相対的なパフォーマンスについて結論を出すべきではありません。 古いバージョンを実行したときにCPUが他のタスクを並行して実行しているという理由だけで、新しいバージョンの実行速度が速くなる場合があります。

さらに、実行時間が作業単位によって異なる可能性がある場合は、コードが実際に遭遇するタスクを表す、ランダムに選択されたいくつかの単位の時間を測定する必要があります。

したがって、方法論的に正しいためには、 さまざまなユニットでのさまざまな実行の測定時間の分布を比較する必要があります。

5.1. 設定

-番目のユニットの古いバージョンの-番目の実行の実行時間とします。 同様に、同じ-番目のユニットの新しいバージョンの-番目の実行時間を示します。

ユニットと実行では、実行時間の2つのマトリックスがあります。 改善を見積もるには、これらのマトリックスを比較する必要があります。 対応する要素が一致するかどうかに応じて、2つの方法で進めることができます。

5.2. 一致した実行

理想的には、すべての実行を同じ条件で実行します。 たとえば、これは、他のプロセスが並行して実行されているために発生するのと同じ過負荷がCPUに発生することを意味します。 または、実行が乱数の生成に依存している場合は、すべての-番目の実行で同じシードを使用します。 このような場合、時間の間に1対1の対応があるため、実行が一致すると言います(にのみ対応し、その逆も同様です)。

全体的な改善を得るために、行列内の一致した要素に対して計算されたペアごとの改善を平均することができます。

(4)  

これは、前のセクションで説明した改善スコアの1つです。 写真は千の言葉の価値があるので、スコアの分布のプロットを平均に添える必要があります。 ほとんどのスコアが高い場合、それは新しいバージョンが古いバージョンよりも高速であることを示す強力な証拠です。

5.3. 実行が一致しない場合はどうなりますか?

との間に自然な対応がない場合、同じユニットで実行したすべての実行を一致させることができます。より具体的には、同じとを計算する代わりに、それぞれを(すべてについて)比較します。

(5)  

この場合、バージョンごとに異なる数の実行を行うことができますが、通常は、両方のバージョンに同じ計算量を費やすことをお勧めします。

5.4. 例

3つのタスクでコードを4回実行し、時間が一致しているとしましょう。

   

式( 4 )と改善定義( 2 )を使用すると、平均的な改善が得られます。

   

したがって、新しいコードは、古いコードが1つのユニットを完了するまでに、平均して1.42のタスクを完了すると結論付けます。 パーセンテージに関しては、142%の改善です。

5.5. 統計的検定

さらに、統計的検定を実行して、実際の改善が100%を超えているかどうかを確認できます。 1つの方法は、100%を超える個々のスコアをカウントし、そのようなスコアの比率の周りに信頼区間を構築することです。 間隔が大きな割合をカバーしている場合、新しいコードがより高速であり、結果が偶然によるものではないことをかなり確信できます。

6. 結論

この記事では、パフォーマンスメトリックが時間である場合の改善率の計算方法について説明しました。 2つの式を示し、統計的な観点からも問題について説明しました。