9

http://benchmarksgame.alioth.debian.org/の言語シュートアウトベンチマークは、FPCプログラムがg++を使用する同等のプログラムが使用するメモリの約50分の1を使用することを示しています。これらのベンチマークは意図せずにfpcを支持しているのでしょうか、それともFPCがg ++よりもはるかに優れているというのは本当ですか？私は常にこれらのベンチマークをまともなマイクロベンチマークのコレクションと見なしてきました。50倍はかなり重要なIMHOであるため、これらの結果には驚いています。

参照：

http://benchmarksgame.alioth.debian.org/u32/pascal.php http://benchmarksgame.alioth.debian.org/u64q/pascal.html

編集：このページでは、pascalが一部のプログラムに8KBしか使用していないと主張している ため、これはさらに興味深いものになっています。これは驚くほど低いようです。

4

2 に答える 2

11

起動時間は、FPCがピークに達するIIRCのもう1つのベンチマークであることに注意してください

答えは主に、Free Pascalがデフォルトでプログラムを静的にリンクし、libcやその他の補助ライブラリを回避するという事実に基づいて求められる必要があると思います。

これにはいくつかの結果があります。

  • ベンチマークされている単純なプログラムの場合、FPCプログラムは独自のRTLのみを使用して静的であり（libcの静的コピーはありません）、動的リンクのオーバーヘッドはありません（時間とメモリの両方）。アプリケーションメモリの使用と間違えられる可能性のある共有glibcセグメントのマッピング（これはそうですか？）を含みます。
  • libcは、潜在的に不要であるが、FPCがこれらの単純なプログラムに対して実行しない初期化を伴う可能性があります。（zoneinfoの初期化など）
  • FPCは完全に独立したメモリマネージャーを使用するため、ヒープサブアロケーターの最初のブロックのサイズが異なる場合があります。おそらくFPCは体系的に小さいです。
  • スレッドの場合、新しいスレッドのスタックのサイズによってさまざまな違いが生じる可能性があります（サイズと、それが（部分的に）予約メモリまたはコミットされたメモリ、または* nixに相当するものである場合の事実）

全体として、この観察された動作はFPCに関するものではなく、他のベンチマーク開発システム間のばらつきの欠如に関するものだと思います。FPCは、他のほとんどすべてがgcc / glibcテクノロジー上に構築されているため（直接gcc派生であるか、VM /インタープリターがgcc上に構築されているため）、すべてがlibcの一般的な扱いを共有しているため、単に際立っています。FPCが異なることは、単純なプログラムに対する（g？）libcの不適切なスケーリングを強調しているにすぎません。（*）

シュートアウトは、共有アドレス空間が実際に使用されるプライベートバイトではなくカウントされるという意味で、またはサブアロケータによって割り当てられたプライベートバイトとプロセスによって実際に使用されるプライベートバイトを十分に区別しないという意味で、おそらく偏っている可能性があります。ただし、これを整理するにはlibc / libmallocコア開発が必要になる可能性があります。また、シュートアウトはオープンソースであるため、より適切な測定を提供できるかどうかという疑問は未解決です。

それか、（g）libcに根本的な問題があります。（私はその専門家ではありません）。より関連性の高い情報を取得するための可能な解決策は、FreeBSD、またはuclibcを使用したLinuxでベンチマークを実行することです。要するに、glibc以外のものです。

Igouyの投稿が述べているように、libcにリンクすると、FPCは他の開発システムの（悪い）特性を取得します。これは、「なぜFPCがシュートアウトベンチマークでうまく機能するのか」ではなく、「バイナリを使用するglibcがシュートアウトメモリベンチマークでパフォーマンスが悪いのはなぜか」という質問であるべきであることを示すもう1つの指標です。

FPCは、パフォーマンスやファイルサイズではなく、クロスディストリビューションの互換性の懸念から、元々libcを回避していたことに注意してください。

それで、これがFPCのメモリ使用量を測定するためのまぐれであると仮定するすべての人にとって、それがglibcメモリ使用量またはその測定の問題であると考えたことはありますか？むしろ、高いglibc番号は間違っており、低いFPC番号ではありません。

....FPC開発者...。

（*）そして、単に「サイズの大きい」アプリケーションに対して効率的に開発されていると言う前に、Unixの哲学は小さなツールを連鎖させることであり、多くのUnixプロセスは短命であることを忘れないでください。

于 2012-06-28T19:15:44.590 に答える
5

はい、 unix ユーティリティのtopが、これらの Pascal プログラムがそれだけ多くのメモリを使用し、それらの C++ プログラムがそれだけ多くのメモリを使用していると報告するのは本当です。

たとえば、x64 では、Free Pascal n-body プログラムが実行されている間、およびC++ n-body プログラムが実行されている間、topはこれらの測定値を報告します --

VIRT        RES       SHR
 608          4         0 FPC
7208        420       332 C++

フリー パスカル プログラムのメモリ使用量上位レポートは、 ベンチマーク ゲームがフリー パスカル プログラムについて報告するメモリ使用量です。

そのx64クアッドコアの比較を見てください

2 つの異なるケースを見ることができます。

  1. Pascal プログラムと C++ プログラムはどちらも複数の MB を使用し、メモリ使用量は非常に似ており、違いは ~2x 未満です。タスクを解決するために追加のメモリが割り当てられている場合、プログラム間に大きな違いはありません。

  2. C++ プログラムは数百 KB を使用し、Pascal プログラムは数 KB を使用します。タスクを解決するために追加のメモリが割り当てられていない場合、Pascal プログラムが使用するメモリは数百 KB 少なくなります。

質問には 2 つの選択肢がありますが、通常は 3 番目の選択肢があります -何が起こっているのか誤解していますか?

C++ mandelbrot プログラムが Pascal mandelbrot プログラムよりも 4000 倍多くのメモリを使用できるという事実は、OP が信じるには多すぎて、OP には不可能に思えましたが、十分に単純な説明、時間/空間のトレードオフがあります。

C++ プログラムはマルチスレッドで、マルチコアを使用するように書かれています。しかし、Pascal プログラムはシングル スレッドであり、シングル コアを使用するように記述されています。

Pascal マルチスレッド マンデルブロ プログラムのメモリ使用は、C++ マルチスレッド プログラムのメモリ使用と非常によく似ています。

于 2012-06-27T16:01:52.353 に答える