Fortranは、重い計算のためにCよりも最適化が簡単ですか？

https://stackoverflow.com/questions/146159

02-07-2019
|

質問

ときどき、FortranはCに比べて重い計算のために高速であるか、高速であると読みました。それは本当ですか？私はFortranをほとんど知らないことを認めなければなりませんが、これまで見てきたFortranコードは、言語にCにはない機能があることを示していませんでした。

もしそうなら、その理由を教えてください。どの言語やライブラリが数値計算に適しているか教えてはいけません。それを行うためのアプリやライブラリを書くつもりはありません。ただ興味があります。

解決

言語には同様の機能セットがあります。パフォーマンスの違いは、EQUIVALENCE文が使用されない限り、Fortranがエイリアシングが許可されていないという事実に由来しています。エイリアスを持つコードは有効なFortranではありませんが、これらのエラーを検出するのはコンパイラの責任であり、コンパイラの責任ではありません。したがって、Fortranコンパイラはメモリポインターのエイリアスを無視し、より効率的なコードを生成できるようにします。 Cのこの小さな例を見てください：

void transform (float *output, float const * input, float const * matrix, int *n)
{
    int i;
    for (i=0; i<*n; i++)
    {
        float x = input[i*2+0];
        float y = input[i*2+1];
        output[i*2+0] = matrix[0] * x + matrix[1] * y;
        output[i*2+1] = matrix[2] * x + matrix[3] * y;
    }
}

この関数は、最適化後、Fortranの対応する関数よりも遅くなります。なぜそうなのか？出力配列に値を書き込む場合、マトリックスの値を変更できます。結局のところ、ポインターはオーバーラップして、同じメモリチャンク（ int ポインターを含む！）を指す可能性があります。 Cコンパイラは、すべての計算のためにメモリから4つの行列値をリロードすることを強制されます。

Fortranでは、コンパイラは行列値を一度ロードしてレジスタに保存できます。 Fortranコンパイラーはポインター/配列がメモリー内でオーバーラップしないと想定しているため、これが可能です。

幸いなことに、 restrict キーワードとstrict-aliasingはこの問題に対処するためにC99標準に導入されました。最近のほとんどのC ++コンパイラでもサポートされています。このキーワードを使用すると、ポインターが他のポインターとエイリアスしないことをプログラマーが約束するというヒントをコンパイラーに提供できます。厳密なエイリアスとは、プログラマーが異なるタイプのポインターが重複しないことを約束することを意味します。たとえば、 double * は int * と重複しません（ただし、 char * および void * は何とでも重複できます）。

これらを使用すると、CとFortranから同じ速度が得られます。ただし、パフォーマンスが重要な機能でのみ restrict キーワードを使用できるということは、C（およびC ++）プログラムがはるかに安全で簡単に作成できることを意味します。たとえば、無効なFortranコードを考えてみましょう： CALL TRANSFORM（A（1、30）、A（2、31）、A（3、32）、30）。ほとんどのFortranコンパイラーは問題なくコンパイルします警告はありませんが、一部のコンパイラ、一部のハードウェア、および一部の最適化オプションでのみ表示されるバグが発生します。

他のヒント

はい、1980年。 2008年に？依存する

私がプロとしてプログラミングを始めたとき、Fortranの速度優位性に挑戦していました。について読んだことを覚えていますドブス博士にそれを教えて、年長のプログラマーにその記事について話した-彼らは笑った。

したがって、私はこれについて、理論的および実用的な2つの見解を持っています。理論的には、今日のFortranは、C / C ++やアセンブリコードを許可する言語に対して本質的な利点はありません。 実際には今日のFortranは、数値コードの最適化に基づいて構築された歴史と文化の遺産の恩恵を受けています。

Fortran 77までは、言語設計の考慮事項が最適化を主な焦点としていました。コンパイラの理論と技術の状態により、これは多くの場合、コンパイラにコードの最適化のベストショットを与えるために、機能と機能を制限することを意味します。 Fortran 77を、スピードのために機能を犠牲にしたプロのレースカーと考えるのは良い例えです。最近では、コンパイラーはすべての言語で改善されており、プログラマーの生産性のための機能がより重視されています。ただし、人々が主に科学計算の速度に関心を持っている場所はまだあります。これらの人々は、Fortranプログラマーである人々からコード、トレーニング、文化を継承している可能性が高いです。

コードの最適化について話し始めると、多くの問題があり、このことを感じる最良の方法は高速な数値コードを取得することが仕事である人々の場所に潜んでいます。しかし、このような非常に機密性の高いコードは、通常、コードの行全体のごく一部であり、非常に特殊化されていることに留意してください。Fortranコードの多くは、「非効率的」です。他の言語の多くの他のコードおよび最適化は、主要な関心事でさえないはずです。そのようなコード。

Fortranの歴史と文化について学ぶには、wikipediaが最適です。 Fortran Wikipediaのエントリは素晴らしいものであり、作成に時間と労力を費やしてくれた人々に感謝します。 Fortranコミュニティにとって価値のあるもの。

（この回答の短縮版は、 Nils によって開始された優れたスレッドのコメントでしたが、それを行うためのカルマはありません。実際、私はおそらく書かなかったでしょうそれ以外は、このスレッドの実際の情報コンテンツと共有があり、フレームワークや言語の偏見とは対照的です。これは、このテーマの主な経験です。私は圧倒され、愛を共有しなければなりませんでした。）

Fortranは、コンパイラの最適化を念頭に置いてある程度設計されています。この言語は、コンパイラーが並列処理を利用できる配列操作全体をサポートしています（特にマルチコアプロセッサー上）。たとえば、

密行列の乗算は単純です：

matmul(a,b)

ベクトルxのL2ノルムは次のとおりです。

sqrt(sum(x**2))

FORALL 、 PURE などのその他のステートメント＆amp; ELEMENTAL プロシージャなどは、コードの最適化にさらに役立ちます。この単純な理由により、FortranのポインターでさえCと同じくらい柔軟です。

次期Fortran規格（2008）には、並列コードを簡単に記述できるco-arrayがあります。 G95（オープンソース）およびCRAYのコンパイラーはすでにサポートしています。

したがって、コンパイラはC / C ++よりも最適化/並列化できるため、Fortranは高速になります。しかし、人生の他のすべてのものと同様に、良いコンパイラと悪いコンパイラがあります。

ここでは、言語を知らないことから多くの答えを得ているのは面白いです。これは特に、古いFORTRAN 77コードを開いて弱点について議論したC / C ++プログラマーに当てはまります。

速度の問題は、主にC / C ++とFortranの間の問題だと思います。巨大なコードでは、常にプログラマーに依存します。 Fortranに勝る言語の機能とCが行う機能があります。したがって、2011年には、どっちが速いかを誰も実際に言うことができません。

言語自体について、Fortranは現在、完全なOOP機能をサポートしており、完全な下位互換性があります。 Fortran 2003を徹底的に使用しましたが、Fortran 2003を使用するのは楽しいことだと思います。一部の側面では、Fortran 2003はまだC ++の背後にありますが、使用方法を見てみましょう。 Fortranは主に数値計算に使用され、速度上の理由から、派手なC ++ OOP機能を使用する人はいません。ハイパフォーマンスコンピューティングでは、C ++に行く場所がほとんどありません（MPI標準を見て、C ++が非推奨になっていることがわかります！）。

最近では、FortranとC / C ++を使用して混合言語プログラミングを簡単に行うことができます。 FortranにはGTK +用のインターフェースもあります。無料のコンパイラ（gfortran、g95）と多くの優れた市販のコンパイラがあります。

Fortranが高速になる理由はいくつかあります。ただし、重要な金額はあまり重要ではないか、とにかく回避できるため、問題ではありません。今日Fortranを使用する主な理由は、レガシーアプリケーションの保守または拡張です。

関数のPUREおよびELEMENTALキーワード。これらは副作用のない関数です。これにより、コンパイラが同じ値で同じ関数が呼び出されることがわかっている特定の場合に最適化が可能になります。注：GCCは＆quot; pure＆quot;を実装しています言語の拡張として。他のコンパイラも同様です。モジュール間分析もこの最適化を実行できますが、それは困難です。
個々の要素ではなく、配列を処理する関数の標準セット。 sin（）、log（）、sqrt（）のようなものは、スカラーの代わりに配列を取ります。これにより、ルーチンの最適化が容易になります。これらの関数がインラインまたは組み込み関数である場合、ほとんどの場合、自動ベクトル化は同じ利点を提供します
ビルチン複合型。理論的には、これによりコンパイラは特定の場合に特定の命令を並べ替えたり削除したりできますが、struct {double re、im; }; Cで使用されるイディオム。演算子はfortranで複雑な型を操作するため、開発が速くなります。

Fortranを支持する重要なポイントは、Fortranがベクトルベースおよび配列ベースの数学を表現するのにやや適している言語だと思います。上記で指摘されたポインター解析の問題は実際には現実的です。なぜなら、移植可能なコードは、コンパイラーに何かを伝えることができると実際に想定できないからです。ドメインがどのように見えるかに近い方法で計算を表現することには、常に利点があります。よく見ると、Cには実際には配列がありません。 Fortranには本当の意味があります。これにより、特定の種類のアルゴリズム、特に並列マシン向けのコンパイルが容易になります。

実行時システムや呼び出し規約などを深く掘り下げると、Cと最新のFortranは十分に類似しているため、何が変わるのかわかりにくいです。ここでのCは実際にはベースCであることに注意してください。C++はパフォーマンス特性がまったく異なる、まったく異なる問題です。

ある言語が別の言語よりも速いということはないので、適切な答えはいいえです。

本当に必要なのは、「FortranコンパイラXでコンパイルされたコードは、CコンパイラYでコンパイルされた同等のコードよりも高速ですか？」もちろん、この質問に対する答えは、どちらのコンパイラを選択するかによって異なります。

もう1つの質問は、「コンパイラで最適化するのと同じ労力を費やせば、どのコンパイラがより高速なコードを生成しますか？」これに対する答えは、実際には Fortran です。 Fortranコンパイラには、証明書の利点があります：

Fortranは、コンパイラを使用しないことを誓った日にはアセンブリと競合する必要があったため、スピードを重視して設計されました。 Cは柔軟に設計されました。
Fortranのニッチ市場は数が増え続けています。このドメインでは、コードは十分に高速ではありません。そのため、言語を効率的に保つために常に多くのプレッシャーがありました。
コンパイラの最適化に関する研究のほとんどは、Fortranの数値計算コードの高速化に関心のある人々によって行われているため、Fortranコードの最適化は、他のコンパイル済み言語を最適化するよりもよく知られている問題であり、Fortranコンパイラーに最初に新しいイノベーションが現れます。
大物：Cは、Fortranよりもはるかに多くのポインタの使用を推奨しています。これにより、Cプログラムのデータ項目の潜在的な範囲が大幅に増加し、最適化がはるかに難しくなります。 Adaはこの領域ではCよりもはるかに優れており、一般的に見られるFortran77よりもはるかに現代的なオブジェクト指向言語であることに注意してください。 Cよりも高速なコードを生成できるオブジェクト指向言語が必要な場合、これはオプションです。
Fortranコンパイラの顧客は、Cコンパイラの顧客よりも数が多いため、最適化を重視する傾向があります。

ただし、Cコンパイラの最適化に多大な労力を費やし、プラットフォームのFortranコンパイラよりも優れたコードを生成することを誰かが妨げることはありません。実際、Cコンパイラによって生成される売り上げが大きいため、このシナリオは非常に実現可能です

FortranがCとは異なる別の項目があり、潜在的に高速です。 FortranにはCよりも優れた最適化ルールがあります。Fortranでは、式の評価順序が定義されていないため、コンパイラーは式を最適化できます。特定の順序を強制する場合は、括弧を使用する必要があります。 Cでは、順序ははるかに厳密ですが、「-fast」を使用すると、オプション、よりリラックスして＆quot;（...）＆quot;無視されます。 Fortranには、中間にある方法があると思います。（まあ、IEEEは特定の評価順序の変更がオーバーフローを発生させないことを要求するので、ライブをより難しくします。オーバーフローは無視されるか、評価を妨げます）。

よりスマートなルールの別の領域は、複素数です。 CがCを持っているのはC 99までかかっただけでなく、それらを管理する規則もFortranの方が優れています。 gfortranのFortranライブラリは部分的にCで書かれていますが、Fortranのセマンティクスを実装しているため、GCCはオプション（「通常」のCプログラムでも使用できます）を獲得しました。

-fcx-fortran-rules 複素数の乗算と除算は、Fortranの規則に従います。範囲の縮小は複素除算の一部として行われますが、複素乗算または除算の結果が「NaN + I * NaN」であるかどうかのチェックは行われず、その場合の状況を救おうとします。

上記のエイリアスルールはもう1つのボーナスであり、少なくとも原則として、コンパイラーのオプティマイザーによって適切に考慮されると、コード全体を高速化できる配列全体の操作も可能になります。反対に、特定の操作にはさらに時間がかかります。割り当て可能な配列に割り当てを行う場合、多くのチェックが必要です（再割り当てしますか？[Fortran 2003の機能]、配列ストライドなど）。これにより、単純な操作が舞台裏でより複雑になります。言語をより強力にします。一方、柔軟な境界とストライドを使用した配列操作により、コードの記述が簡単になります。通常、コンパイラはユーザーよりもコードを最適化する方が優れています。

合計すると、CとFortranはどちらもほぼ同じくらい高速だと思います。選択する言語は、どの言語の方が好きか、Fortranの配列全体の操作を使用して移植性を向上させる方が便利か、またはCのシステムおよびグラフィカルユーザーインターフェイスライブラリとのインターフェイスを改善するかです。

特定の目的で一方を他方より速くする言語 FortranとCには何もありません。これらの各言語の特定のコンパイラには、特定のタスクに他のタスクよりも有利になるものがあります。

長年、Fortranコンパイラが存在し、数値ルーチンに黒魔術をかけ、多くの重要な計算を非常に高速に実行できました。現代のCコンパイラはそれもできませんでした。その結果、Fortranでは多くの優れたコードライブラリが成長しました。これらの十分にテストされた成熟した素晴らしいライブラリを使用したい場合は、Fortranコンパイラを使用します。

私の非公式の観察によると、最近の人々は重い計算を古い言語でコーディングしており、少し時間がかかると安価な計算クラスターで時間を見つけます。ムーアの法則は私たちすべてを馬鹿にします。

Fortran、C、C ++の速度をnetlibの古典的なLevine-Callahan-Dongarraベンチマークと比較します。 OpenMPを使用した複数言語バージョンは http://sites.google.com/site/tprincesite/levine-callahan -dongarra-vectors Cは自動翻訳に始まり、特定のコンパイラの制限とプラグマの挿入から始まったため、Cいです。 C ++は、該当する場合、STLテンプレートを使用した単なるCです。私の考えでは、STLは保守性を向上させるかどうかについてはさまざまな問題を抱えています。

例はインライン化にほとんど依存していない従来のFortranのプラクティスに基づいているため、最適化をどの程度改善するかを確認するための自動関数インライン化の最小限の演習しかありません。

これまでで最も広く使用されているC / C ++コンパイラには、これらのベンチマークが大きく依存している自動ベクトル化がありません。

この直前の投稿について：Fortranで括弧を使用して、より高速またはより正確な評価順序を指定する例がいくつかあります。既知のCコンパイラには、より重要な最適化を無効にすることなく括弧を監視するオプションがありません。

私は数年間、FORTRANとCを使っていくつかの広範な数学を行っていました。私自身の経験から、FORTRANはCよりも優れていることもありますが、その速度（適切なコーディングスタイルを使用してCをFORTRANと同じくらい高速に実行できる）ではなく、LAPACKなどの非常によく最適化されたライブラリのために、優れた並列化。私の意見では、FORTRANは本当に扱いにくく、その利点はその欠点を解消するのに十分ではないため、C + GSLを使用して計算を行っています。

私は趣味のプログラマであり、「平均的」です。両方の言語で。 C（またはC ++）コードよりも高速なFortranコードを書く方が簡単だと思います。 FortranとCはどちらも＆quot; historic＆quot;です。言語（今日では標準）は頻繁に使用され、無料および商用のコンパイラを十分にサポートしています。

これが歴史的な事実かどうかはわかりませんが、Fortranは並列化/分散化/ベクトル化/何でもコア化できるように構築されているように感じます。そして今日、それはほとんど「標準的な指標」です。速度について話しているとき：＆quot;スケーリングしますか？＆quot;

純粋なCPU演算処理では、Fortranが大好きです。 IO関連の場合は、Cで作業する方が簡単だと思います（どちらの場合も難しいです）。

もちろん、並列計算を多用するコードの場合は、おそらくGPUを使用する必要があります。 CとFortranの両方には、CUDA / OpenCLインターフェースが多かれ少なかれ統合されています（現在はOpenACC）。

中程度に客観的な答えは：両方の言語を等しく/貧弱に知っているなら、FortranはCよりも並列/分散コードを書く方が簡単だと思うので、Fortranの方が速いと思います（＆quot;厳密なF77コードだけでなく、フリーフォーム＆quot; fortran）

第1の回答が気に入らないので、私を支持したい人のための第2の回答は次のとおりです。そのため、実装しているアルゴリズム（CPU集中型、IO集中型、メモリ集中型）、ハードウェア（単一CPU、マルチコア、分散スーパーコンピューター、GPGPU、FPGA）、スキル、そして最終的にはコンパイラーに依存します。 CとFortranの両方に素晴らしいコンパイラがあります。（私は、Fortranコンパイラーがどれほど高度であるかに真剣に驚いていますが、Cコンパイラーもそうです。）

PS：Fortran GUIライブラリについて多くの悪いことを言っているので、特にlibを除外してくれてうれしいです。：）

FortanがCよりも大幅に高速だと聞いたことはありませんが、特定の場合には高速になると考えられます。そして、キーは、存在する言語機能ではなく、（通常）存在しない機能にあります。

例はCポインターです。 Cポインターはほとんどどこでも使用されますが、ポインターの問題は、コンパイラーが通常、同じ配列の異なる部分を指しているかどうかを判断できないことです。

たとえば、次のようなstrcpyルーチンを作成した場合：

strcpy(char *d, const char* s)
{
  while(*d++ = *s++);
}

コンパイラは、dとsが重複する配列である可能性があるという仮定の下で動作する必要があります。そのため、配列が重複する場合に異なる結果を生成する最適化を実行できません。ご想像のとおり、これにより実行できる最適化の種類が大幅に制限されます。

[C99には「制限」があります。ポインターが重複しないことをコンパイラーに明示的に伝えるキーワード。また、FortranにもCのセマンティクスとは異なるセマンティクスを持つポインターがありますが、ポインターはCのように遍在していないことに注意してください。]

しかし、C対Fortranの問題に戻ると、Fortranコンパイラーは（直接記述された）Cプログラムでは不可能な最適化を実行できると考えられます。ですから、私はその主張にあまり驚かないでしょう。ただし、パフォーマンスの違いはそれほど大きくないと予想しています。 [〜5-10％]

FortranとCの速度の違いは、コンパイラーの最適化と、特定のコンパイラーが使用する基礎となる数学ライブラリーの関数になります。 Cよりも高速にするFortran固有の機能はありません。

とにかく、優秀なプログラマーはどの言語でもFortranを書くことができます。

すばやく簡単： どちらも同等に高速ですが、Fortranはよりシンプルです。 最終的に本当に速いのはアルゴリズムに依存しますが、とにかく速度の差はほとんどありません。これは、2015年にドイツのシュトゥットガルトにある高性能コンピューティングセンターで行われたFortranワークショップで学んだことです。私はFortranとCの両方で働き、この意見を共有しています。

説明：

Cは、オペレーティングシステムを記述するために設計されました。したがって、高性能コードを書くために必要な以上の自由があります。一般にこれは問題ありませんが、慎重にプログラミングしないと、コードを簡単に遅くすることができます。

Fortranは科学プログラミング向けに設計されました。このため、Fortranの主な目的である構文上の高速コードの記述をサポートしています。世論とは対照的に、Fortranは時代遅れのプログラミング言語ではありません。最新の標準は2010年であり、新しいコンパイラは定期的に公開されています。これは、ほとんどの高性能コードがFortranで記述されているためです。 Fortranコンパイラディレクティブ（Cプラグマ）として最新の機能をさらにサポートします。

例： 関数への入力引数として大きな構造体を指定します（fortran：サブルーチン）。関数内では引数は変更されません。

Cは、参照による呼び出しと値による呼び出しの両方をサポートしています。これは便利な機能です。この場合、プログラマーは誤って値渡しを使用する可能性があります。これにより、構造体を最初にメモリ内にコピーする必要があるため、処理速度が大幅に低下します。

Fortranは参照による呼び出しでのみ動作します。これにより、プログラマーが実際に値による呼び出し操作が必要な場合は、手動で構造体をコピーする必要があります。私たちの場合、fortranは、参照渡しのCバージョンと同じくらい自動的に高速になります。

一般に、FORTRANはCよりも低速です。Cはハードウェアレベルのポインターを使用して、プログラマーが手動で最適化できるようにします。 FORTRAN（ほとんどの場合）は、ハードウェアメモリアドレス指定ハックにアクセスできません。（VAX FORTRANは別の話です。）私は70年代からFORTRANのオンとオフを使用しています。（本当に。）

ただし、90年代以降、FORTRANは、マルチコアプロセッサで実際に叫ぶことができる本質的に並列アルゴリズムに最適化できる特定の言語構成要素を含むように進化しました。たとえば、自動ベクトル化により、複数のプロセッサがデータのベクトル内の各要素を同時に処理できます。 16プロセッサ-16要素ベクトル-処理にかかる時間は1/16です。

Cでは、独自のスレッドを管理し、マルチプロセッシング用にアルゴリズムを慎重に設計してから、一連のAPI呼び出しを使用して、並列処理が適切に行われるようにする必要があります。

FORTRANでは、マルチプロセッシング用にアルゴリズムを慎重に設計するだけです。コンパイラーとランタイムが残りを処理します。

高性能について少し読むことができます。 Fortran ですが、デッドリンクがたくさんあります。並列プログラミング（ OpenMP.org など）と、FORTRANがそれをどのようにサポートしているかについて読むことをお勧めします。

より高速なコードは実際には言語に依存していません。コンパイラなので、ms-vb＆quot; compiler＆quot;を見ることができます。これは、「。exe」内で結び付けられた肥大化した低速で冗長なオブジェクトコードを生成しますが、powerBasicはあまりにも優れたコードを生成します。 CおよびC ++コンパイラーによって作成されたオブジェクトコードは、いくつかのフェーズ（少なくとも2）で生成されますが、設計上、ほとんどのFortranコンパイラーには、高度な最適化を含む少なくとも5つのフェーズがあるため、設計上、Fortranは常に高度に最適化されたコードを生成できます。最後に、コンパイラはあなたが求めるべき言語ではなく、私が知っている最高のコンパイラはIntel Fortranコンパイラです。なぜなら、それはLINUXとWindowsで入手でき、あなたが探しているならVSをIDEとして使用できるからですOpenWatcomでいつでも中継できる安価なコンパイラ。

これに関する詳細情報： http://ed-thelen.org/1401Project/1401-IBM -Systems-Journal-FORTRAN.html

Fortranには、より優れたI / Oルーチンがあります。暗黙のdo機能は、Cの標準ライブラリが対応できない柔軟性を提供します。

Fortranコンパイラはより複雑なものを直接処理します含まれる構文、およびそのような構文を簡単に減らすことはできません引数を渡す形式では、Cはそれを効率的に実装できません。

最新の標準とコンパイラを使用、いいえ！

一部の人々は、コンパイラがエイリアスを心配する必要がないため、FORTRANの方が速いことを示唆しています（したがって、最適化中により多くの仮定を行うことができます）。ただし、restrictキーワードを含めるC99（私が思う）標準以来、これはCで処理されています。これは基本的にコンパイラに、特定のスコープ内ではポインタがエイリアスされていないことを伝えます。さらに、Cは適切なポインター演算を可能にします。この場合、エイリアスやパフォーマンスは、パフォーマンスやリソースの割り当ての点で非常に役立ちます。 FORTRANの最新バージョンでは＆quot; proper＆quot;の使用が可能になると思いますがポインター。

最新の実装では、C全般はFORTRANよりも優れています（ただし、非常に高速です）。

http://benchmarksgame.alioth.debian.org/u64q/fortran.html

編集：

これに対する公正な批判は、ベンチマークが偏っている可能性があるということです。結果をより多くのコンテキストに配置する別のソース（Cに対して）を次に示します。

http://julialang.org/benchmarks/

ほとんどの場合、Cは通常Fortranよりも優れていることがわかります（ここでも以下の批判を参照してください）。他の人が述べたように、ベンチマークは、ある言語を他の言語よりも優先させるために簡単にロードできる不正確な科学です。しかし、FortranとCが同様のパフォーマンスをどのように持っているかをコンテキストに入れています。

Fortranは、配列、特に多次元配列を非常に便利に処理できます。 Fortranでの多次元配列の要素のスライスは、C / C ++の場合よりもはるかに簡単です。 C ++には、BoostやEigenなどの仕事をすることができるライブラリがありますが、それらはすべて外部ライブラリです。 Fortranでは、これらの関数は組み込みです。

Fortranの開発が高速であるか、開発で便利であるかは、主に終了する必要があるジョブに依存します。地球物理学の科学計算者として、Fortranでほとんどの計算を行いました（現代のFortran、＆gt; = F90を意味します）。

これはやや主観的なものです。コンパイラーなどの品質に影響を与えるからです。ただし、言語/コンパイラーの観点から言えば、より直接的にあなたの質問に答えるには、Fortran over Cについて本質的にCよりも高速または優れたものはありません。重い数学演算をしている場合は、コンパイラの品質、各言語のプログラマーのスキル、および組み込み数学は、これらの操作をサポートするライブラリをサポートし、特定の実装でどちらが高速になるかを最終的に決定します。

編集：@Nilsなどの他の人々は、Cでのポインターの使用の違いと、おそらく最も素朴な実装をCで遅くするエイリアシングの可能性について良い点を挙げています。しかし、対処する方法がありますC99では、コンパイラ最適化フラグを介して、および/またはCが実際にどのように記述されているか。これについては、@ Nilsの回答と彼の回答に続く後続のコメントで詳しく説明しています。

ほとんどの投稿にはすでに説得力のある議論があります。そのため、別の側面に2セントのことわざを追加します。

最終的に処理能力の点でフォートランを高速化または低速化することは重要ですが、Fortranで何かを開発するのに5倍の時間がかかる場合：

純粋な数値計算とは異なるタスクに適したライブラリが不足しています
ドキュメント作成と単体テストのための適切なツールが欠けている
非常に表現力の低い言語であり、コードの行数が急増しています。
文字列の処理が非常に悪い
これは、さまざまなコンパイラーやアーキテクチャーの間で非常に多くの問題を抱えており、あなたを夢中にさせます。
IO戦略が非常に貧弱です（シーケンシャルファイルの読み取り/書き込み。はい、ランダムアクセスファイルは存在しますが、使用されたことはありますか？）
優れた開発手法、モジュール化は奨励していません。
完全に標準的で完全に準拠したオープンソースコンパイラが事実上欠けています（gfortranとg95の両方がすべてをサポートしているわけではありません）
Cとの相互運用性が非常に悪い（マングリング：アンダースコア1つ、アンダースコア2つ、アンダースコアなし、一般にアンダースコア1つ、別のアンダースコアがある場合は2つ。共通ブロックを掘り下げないでください...）

その後、問題は無関係です。何かが遅い場合、ほとんどの場合、一定の制限を超えて改善することはできません。もっと速くしたい場合は、アルゴリズムを変更してください。最後に、コンピューターの時間は安いです。人間の時間はそうではありません。人間の時間を短縮する選択を大切にします。コンピューターの時間が長くなっても、とにかく費用対効果が高くなります。

Fortranは伝統的に-fp：strict（f2003標準の一部であるUSE IEEE_arithmeticの一部の機能を有効にするために必要です）などのオプションを設定しません。インテル®C ++は-fp：strictをデフォルトとして設定しませんが、たとえばERRNOの処理に必要です。また、他のC ++コンパイラーは、ERRNOをオフにしたり、simdリダクションなどの最適化を取得したりしません。 gccとg ++では、Makefileを設定して、危険な組み合わせ-O3 -ffast-math -fopenmp -march = nativeを使用しないようにする必要がありました。これらの問題以外に、相対的なパフォーマンスに関するこの質問はより厳しく、コンパイラとオプションの選択に関するローカルルールに依存します。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow