6

Computer LanguageBenchmarkGameでのFortranのパフォーマンスは驚くほど悪いです。今日の結果では、Fortranは2つのクアッドコアテストで14番目と11番目、シングルコアで7番目と10番目になります。

さて、ベンチマークは決して完璧ではないことを私は知っていますが、それでも、Fortranはハイパフォーマンスコンピューティングの言語と見なされることが多く、このベンチマークで使用される問題の種類は、Fortranの利点になるはずです。計算物理学に関する最近の記事で、Landau（2008）は次のように書いています。

ただし、[Java]は、FORTRANやCほど効率的ではなく、HPCや並列処理でもサポートされていません。後者の2つは、高度に開発されたコンパイラーと、さらに多くの科学的なサブルーチンライブラリーを利用できます。同様に、FORTRANは依然としてHPCの主要な言語であり、FORTRAN 90/95は驚くほど素晴らしく、現代的で効果的な言語です。しかし残念ながら、CS部門からはほとんど教えられておらず、コンパイラーは高価になる可能性があります。

言語シュートアウト（IntelのLinux用無料コンパイラ）で使用されているコンパイラのせいだけですか？

4

6 に答える 6

6

いいえ、これはコンパイラのせいだけではありません。

このようなベンチマーク（プログラムがベンチマークごとに異なる場合）は、主に、プログラマーが特定のプログラムを作成するために費やした労力の量（および労力の質）です。私は、Fortranがその特定のメトリックで重大な不利な点にあると思います-CやC ++とは異なり、ベンチマークプログラムをより良くするために手を試したいプログラマーのプールはかなり少なく、他のほとんどのものとは異なり、彼らにも証明するものがあるとは思わないでください。したがって、生成されたアセンブリコードを調べてプログラムをプロファイリングして処理を高速化するために、誰かが数日を費やす動機はありません。

これは、得られた結果からかなり明らかです。一般に、十分なプログラミング作業と適切なコンパイラがあれば、C、C ++、Fortranのいずれもアセンブリコードよりも大幅に遅くなることはありません。病理学的な場合を除いて、最悪の場合、5〜10％以下です。ここで得られた実際の結果がそれよりも多様であるという事実は、「十分なプログラミング努力」が費やされていないことを私に示しています。

アセンブリにベクトル命令の使用を許可するが、C / C ++ / Fortranに対応するコンパイラ組み込み関数の使用を許可しない場合は例外があります。自動ベクトル化は完全に近いものではなく、おそらく決してそうなることはありません。それらがここでどれだけ適用される可能性があるかはわかりません。

同様に、例外は、ランタイムライブラリ（品質が異なる場合があります。Fortranは、高速の文字列ライブラリがコンパイラベンダーに利益をもたらすことはめったにありません！）に大きく依存する文字列処理などです。 「文字列」の基本的な定義と、それがメモリ内でどのように表されるか。

于 2009-08-06T03:29:06.977 に答える
2

いくつかのランダムな考え：

Fortranは、ループ不変条件の識別が容易であり、コンパイラーの最適化が容易になったため、非常にうまく機能していました。それ以来

  1. コンパイラははるかに洗練されています。特にcおよびc++コンパイラには多大な努力が払われています。fortranコンパイラは追いついてきましたか？gfortranはgccとg++の同じバックエンドを使用していると思いますが、Intelコンパイラはどうですか？以前は良かったのですが、今でもそうですか？
  2. 一部の言語は、コンパイラー（restrictedおよびconst int const *pc、およびinlinec ++）を支援するために多くの特殊なキーワードと構文を取得しています。fortran 90または95を知らないので、これらがペースを維持しているかどうかはわかりません。
于 2009-07-28T21:55:04.437 に答える
2

私はこれらのテストを見てきました。コンパイラが間違っているわけではありません。ほとんどのテストで、FortranはC ++に匹敵しますが、10倍の割合で打ち負かされるものもあります。これらのテストは、最初から知っておくべきことを反映しているだけです。計算は、優れたリスト操作などを備えていますが、たとえば、「フォーマットされていない」IOなどの特定のFortranのようなメソッドで実行しない限り、IOは最悪です。

例を挙げましょう-stdinから1行ずつ大きな（10 ^ 8 Bのオーダーの）ファイルを読み取ることになっている'reverse-complement'プログラムは、それを使って何かを実行し、結果の大きなファイルをに出力します。 stdout。非常に単純なFortranプログラムは、単一コアでは、非常に最適化されたC ++（〜1s）よりも約10倍遅くなります（〜10s）。プログラムを試してみると、単純なフォーマットの読み取りと書き込みだけで8秒以上かかることがわかります。Fortranの方法では、効率を重視する場合は、フォーマットされていない構造をファイルに書き込んで、すぐに読み戻すだけです（これは完全に移植性がなく、とにかく気になります-効率的なコードは高速で特定のマシン用に最適化されており、どこでも実行することはできません）。

つまり、簡単な答えは、「心配しないで、仕事をするだけです」ということです。非常に効率的なオペレーティングシステムを作成したい場合は、申し訳ありませんが、Fortranはそのようなパフォーマンスを実現する方法ではありません。

于 2010-09-20T22:20:06.353 に答える
2

このベンチマークはまったく愚かです。

たとえば、プログラム全体を実行するためのCPU時間を測定します。mcmintが述べたように（そしてそれは実際には本当かもしれませんが）Fortran I/Oは最悪です*。しかし、誰が気にしますか？実際のタスクでは、時間/日/月の計算を行うよりも数秒間入力を読み取り、最後に秒の出力を書き込みます。そのため、ほとんどのベンチマークでは、I / O操作が時間測定から除外されています（もちろん、I / Oを単独でベンチマークしない場合）。

Norber Wienerは、彼の著書God＆Golem、Inc.に次のように書いています。

人間のものを人間に、そしてコンピュータのものをコンピュータにレンダリングしなさい。

私の意見では、任意のプログラミング言語でアルゴリズムを実装する際にこの原則を使用することは、次のことを意味します。

できるだけ読みやすくシンプルなコードを記述し、コンパイラーに最適化を行わせます。

特に、実際の（巨大な）アプリケーションでは重要です。効率をある程度（5％、おそらく10％）向上させる可能性があるとしても、ダーティトリック（多くのベンチマークで非常に頻繁に使用されます）は、実際のプロジェクトには適していません。

/ * C /C++はストリームI/Oを使用しますが、Fortranは伝統的にレコードベースのI/Oを使用します。さらに読む。とにかく、そのベンチマークのI/Oは非常に驚くべきものです。stdin/stdoutリダイレクトの使用も問題の原因である可能性があります。言語または標準ライブラリによって提供されるファイルの読み取り/書き込み機能を単純に使用してみませんか？繰り返しになりますが、これはより現実的な状況です。

于 2010-09-21T09:23:37.877 に答える
2

ベンチマークがFORTRANの最良の結果をもたらさない場合でも、この言語は引き続き使用され、長期間使用されます。使用理由は、パフォーマンスだけでなく、プログラマビリティのしやすさと呼ばれるものでもあります。60年代と70年代にそれを使用することを学んだ多くの人々は、今では新しいものに入るには年を取りすぎており、FORTRANの使用方法をかなりよく知っています。つまり、使用する言語には多くの人的要因があります。プログラマーも重要です。

于 2010-09-22T12:35:26.927 に答える
1

彼らがIntelFortranコンパイラーに使用した正確なコンパイラー・オプションを公開していなかったことを考えると、私は彼らのベンチマークをほとんど信じていません。

また、Intelの数学ライブラリMKLとAMDの数学ライブラリACMLの両方がIntelFortranコンパイラを使用していることにも注意してください。

編集：

ベンチマークの名前をクリックすると、コンパイルオプションが見つかりました。最適化レベルが妥当と思われるため、結果は驚くべきものです。それはアルゴリズムの効率に帰着するかもしれません。

于 2009-07-28T21:46:20.507 に答える