web-dev-qa-db-ja.com

UNIXの「time」コマンドはベンチマークに対して十分正確ですか？

Foo.pyとbar.pyの2つのプログラムをベンチマークしたいとします。

数千回の実行とそれぞれの平均time python foo.pyおよびtime python bar.pyプロファイリングと速度の比較に十分ですか？


編集： さらに、各プログラムの実行が1秒未満である場合（上記の場合ではなかったと想定）、timeを使用しても問題ありませんか？

linuxunixprofilingbenchmarking
45
chrisdotcode

timeは、1秒以上実行されるベンチマークに十分な時間を生成します。そうでない場合、プロセスの実行時間は、実行時間と比較してexec() ingの時間が長くなる可能性があります。

ただし、ベンチマーク時には、コンテキストの切り替えに注意する必要があります。つまり、別のプロセスがCPUを使用している可能性があり、ベンチマークとCPUの競合が発生し、実行時間が長くなる可能性があります。他のプロセスとの競合を回避するには、次のようなベンチマークを実行する必要があります。

Sudo chrt -f 99 /usr/bin/time --verbose <benchmark>

または

Sudo chrt -f 99 perf stat -ddd <benchmark>

Sudo chrt -f 99は、ベンチマークをFIFO優先度99のリアルタイムクラスで実行します。これにより、プロセスが最優先プロセスになり、コンテキストの切り替えが回避されます（/etc/security/limits.confリアルタイムの優先順位を使用するために特権プロセスを必要としないこと）。

また、ベンチマークで発生したコンテキストスイッチの数（通常は0である必要があります）を含む、利用可能なすべての統計情報をtimeで報告します。

perf stat -dddは/usr/bin/timeよりも情報量が多く、サイクルごとの命令、分岐およびキャッシュミスなどの情報を表示します。

また、CPU周波数のスケーリングとブーストを無効にして、ベンチマーク中にCPU周波数が一定になり、一貫した結果が得られるようにすることをお勧めします。

57
Maxim Egorushkin

今日、imo、ベンチマークの目的でtimeを使用する理由はありません。代わりにperf statを使用してください。これにより、はるかに有用な情報が得られ、ベンチマークプロセスを任意の回数繰り返し、結果の統計を実行できます。つまり、分散と平均値を計算できます。これははるかに信頼性が高く、timeと同じくらい簡単に使用できます。

perf stat -r 10 -d <your app and arguments>

-r 10はアプリを10回実行し、その統計を行います。 -dは、キャッシュミスなどのデータをさらに出力します。

したがって、timeは長時間実行されるアプリケーションに対して十分な信頼性があるかもしれませんが、perf statほど信頼性は高くありません。代わりにそれを使用してください。

補遺：本当にtimeを使い続けたい場合は、少なくともbash-builtinコマンドを使用しないでください。詳細モードでの実際の処理：

/usr/bin/time -v <some command with arguments>

次に、出力は次のようになります。

    Command being timed: "ls"
    User time (seconds): 0.00
    System time (seconds): 0.00
    Percent of CPU this job got: 0%
    Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.00
    Average shared text size (kbytes): 0
    Average unshared data size (kbytes): 0
    Average stack size (kbytes): 0
    Average total size (kbytes): 0
    Maximum resident set size (kbytes): 1968
    Average resident set size (kbytes): 0
    Major (requiring I/O) page faults: 0
    Minor (reclaiming a frame) page faults: 93
    Voluntary context switches: 1
    Involuntary context switches: 2
    Swaps: 0
    File system inputs: 8
    File system outputs: 0
    Socket messages sent: 0
    Socket messages received: 0
    Signals delivered: 0
    Page size (bytes): 4096
    Exit status: 0

特に、これがどのようにピークRSSを測定できるかに注意してください。これは、ピークメモリ消費に対するパッチの影響を比較する場合に十分な場合が多いです。つまりその値を使用して前後を比較し、RSSピークに大幅な減少がある場合は、正しいことを行いました。

48
milianw

はい、timeは十分正確です。また、プログラムを数十回実行するだけで済みます（実行時間が1秒以上、または1秒のかなりの部分-つまり、少なくとも200ミリ秒以上）。もちろん、ファイルシステムはほとんどの実行（最初の実行を除く）で高温になるため（つまり、小さいファイルは既にRAMにキャッシュされています）、そのことを考慮に入れてください。

少なくともtime- dを実行して10分の数秒持続させたい理由は、時間測定の精度と粒度です。 100分の1秒未満の精度を期待しないでください。 （1ミリ秒にするには、特別なカーネルオプションが必要です）

アプリケーション内から、 clock 、 clock_gettime 、 gettimeofday 、 getrusage 、 times （確かにPython同等のものがあります）。

time（7） のマニュアルページを読むことを忘れないでください。

4
Basile Starynkevitch

はい。 timeコマンドは、経過時間と消費されたCPUの両方を示します。大量のI/Oを実行しているのでない限り、おそらく後者に焦点を当てるべきです。経過時間が重要な場合は、テストの実行中にシステムに他の重要なアクティビティがないことを確認してください。

2
schtever