なぜ人々は、言語ベンチマークのためにフィボナッチ数列で数を見つけるような些細な数学的問題を使用することに固執するのでしょうか? これらは通常、相対論的な速度に最適化されませんか? 通常、ボトルネックの矢面に立つのは、I/O、システム API 呼び出し、文字列と構造体の操作、大量のデータの処理、抽象的なオブジェクト指向のものなどではないでしょうか?
4 に答える
5
これは、現在基本的な数学と呼ばれるもののコンパイラ テクノロジがまだ急速に進化していた昔への逆戻りです。
現在、コンパイラの進化は、ニッチな操作や 64 ビット演算などの新しい命令を活用することに重点を置いています。
ただし、あなたが言及したようなマイクロベンチマークは、Java が最初に起動されたときの hotspot コンパイラの効率を評価するとき、および .NET と C/C++ の効率を評価するときに役立ちました。
I/O とシステム コールがボトルネックである可能性が高いというあなたの提案は、少なくともある程度の問題については正しいです。しかし、文字列操作を提案したことに気付きました。ある人の無関係なマイクロ ベンチマークは、別の人の重要なパフォーマンス メトリックです。
編集: ps、linpack やその他のマイクロベンチマークを使用して、JVM のバージョンを比較したり、JVM のベンダーを比較したことも覚えています。v4 から v5 ではパフォーマンスが大幅に向上し、JIT コンパイラがより効果的になったと思います。また、IBM の JVM は、当時、Windows-x86 上で Sun よりも優れていました。
于 2009-04-04T23:15:52.193 に答える
3
言語/コンパイラをベンチマークしたい場合、これらの「数学の問題」は、生成されたコードの「裸の速度」の良い指標になるためです。タイトなループであり、コンパイラがプロセッサに命令をプッシュできるかを示す反復ソリューションを使用するか、短い関数の再帰呼び出し (インライン化、末尾再帰) をどのように処理するかを示す再帰ソリューションを使用します。など) (ただし、通常はアッカーマン関数も使用されます)。
通常、言語のベンチマーク スイートには、他の部分のベンチマーク テストも含まれています。gzip 圧縮、テキスト検索、オブジェクト作成、仮想関数呼び出し、例外スロー/キャッチ ベンチマーク。
あなたが気づいた他のこと、syscallsとIOは通常含まれていません。
実際、システムコールはそれほど遅くはありません。アプリケーションは、特に対象となるテストや、プログラムに深刻な問題がある場合を除いて、カーネルで多くの時間を費やしません。
syscall と IO のパフォーマンスは言語に依存するのではなく、OS とハードウェアに依存します。
于 2009-04-04T23:34:35.923 に答える
2
シンプルで確立されたアルゴリズムにより、ベンチマークが (無知または悪意によって) 1 つの言語を優先するように偏っている可能性が排除されると思います。2 つの異なる言語でまったく同じ複雑なプログラムを作成することは非常に困難です。たとえば、c# と Java のマルチスレッド アプリケーションの効率などをテストするには、開発者が両方の言語のマルチスレッド開発に熟練している必要があり、ベンチマーク アプリが一般的なケースを適切に表しているかどうか、または誤って伝えているかどうかについては、依然として疑問があります。 1 つの言語だけが適切に処理される特殊なケースです。
于 2009-04-04T23:25:09.940 に答える
1
エラトスタンのふるいがCコンパイラの人気のベンチマークだった頃、コンパイラの作成者の1人がふるいコードを認識し、事前に計算されたルックアップに置き換えると面白いと思いました。
于 2009-04-05T03:54:49.980 に答える