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

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この問題に対処するために、キーワードと厳密なエイリアスが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コミュニティーにとって価値のあるものにするために時間と労力を費やしてくれた方々に大変感謝しています。

（この回答の短縮版は、Nilsによって開始された優れたスレッドでのコメントでしたが、私にはそれを行うためのカルマがありません。実際、私はおそらく何も書かなかったでしょうが、このスレッドには実際の炎の戦争と言語の偏見とは対照的に、情報コンテンツと共有。これは、この主題に関する私の主な経験です。私は圧倒され、愛を共有する必要がありました。）

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

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

matmul(a,b)

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

sqrt(sum(x**2))

さらにFORALL、PURE＆などのステートメント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はまだC ++の背後にありますが、使用法を見てみましょう。Fortranは主に数値計算に使用されますが、速度上の理由から、誰も豪華なC ++ OOP機能を使用していません。ハイパフォーマンスコンピューティングでは、C ++を使用する場所がほとんどありません（MPI標準を確認すると、C ++が非推奨になっていることがわかります）。

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

Fortranが高速になる理由はいくつかあります。しかし、それらが重要な量は非常に重要ではないか、とにかく回避することができるので、重要ではありません。今日Fortranを使用する主な理由は、レガシーアプリケーションを維持または拡張することです。

• 関数のPUREおよびELEMENTALキーワード。これらは副作用のない関数です。これにより、コンパイラが同じ関数が同じ値で呼び出されることがわかっている特定のケースで最適化が可能になります。注：GCCは、言語の拡張機能として「純粋」を実装しています。他のコンパイラも同様です。モジュール間分析でもこの最適化を実行できますが、困難です。

• 個々の要素ではなく配列を処理する関数の標準セット。sin（）、log（）、sqrt（）のようなものは、スカラーの代わりに配列を取ります。これにより、ルーチンの最適化が容易になります。自動ベクトル化は、これらの関数がインラインまたは組み込みの場合、ほとんどの場合に同じ利点を提供します

• 組み込みの複合型。理論的には、これによりコンパイラーが特定の場合に特定の命令を並べ替えたり削除したりできるようになりますが、struct {double re、im; }; Cで使用されているイディオム。演算子はfortranの複雑な型を処理するため、開発が速くなります。

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

ランタイムシステムや呼び出し規約などの詳細については、Cと最新のFortranは非常に似ているため、何が違いを生むのかわかりません。ここでのCは実際にはベースCであることに注意してください。C++はまったく異なる問題であり、パフォーマンス特性が大きく異なります。

ある言語が別の言語よりも速いということはありません。そのため、適切な答えはnoです。

「CコンパイラYでコンパイルされた同等のコードよりもFortranコンパイラXでコンパイルされたコードは高速ですか？」もちろん、その質問への答えは、選択した2つのコンパイラによって異なります。

「コンパイラで最適化に費やされたのと同じ量の作業を行うと、どのコンパイラがより高速なコードを生成するのか」という質問に沿って質問することもできます。これに対する答えは、実際にはFortranです。Fortranコンパイラには、certianの利点があります。

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

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

FortranがCとは異なり、より高速である可能性のある別の項目があります。FortranはCよりも優れた最適化ルールを備えています。Fortranでは、式の評価順序が定義されていないため、コンパイラーはそれを最適化できます。特定の順序を強制したい場合は、括弧を使用する必要があります。Cでは順序ははるかに厳しくなっていますが、「-fast」オプションを使用すると、それらはより緩和され、「（...）」も無視されます。Fortranには、真ん中にうまく行く方法があると思います。（まあ、IEEEは、特定の評価順序の変更でオーバーフローが発生しないようにする必要があるため、ライブをより困難にします。オーバーフローは無視するか、評価を妨げる必要があります）。

よりスマートなルールのもう1つの領域は、複素数です。C 99までにCが持っていただけでなく、それらを管理するルールも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 ++は、該当する場合はSTLテンプレートを備えた単なるCです。私の見解では、STLは保守性を向上させるかどうかに関しては混合されたバッグです。

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

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

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

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

それが歴史的事実であるかどうかはわかりませんが、Fortranは並列化/分散/ベクトル化/ whatever-many-cores-izedするように構築されているように感じます。そして今日、私たちが速度について話しているとき、それはほとんど「標準的な指標」です：「それはスケールしますか？」

純粋なCPU処理には、Fortranが大好きです。IOに関連することなら、Cを使用する方が簡単だと思います（どちらにしても難しいです）。

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

私の適度に客観的な答えは：両方の言語を同等または十分に理解している場合、並列/分散コードをCよりもFortranで書く方が簡単であるため、Fortranの方が速いと思います（「フリーフォーム」のFortranを記述できることを理解したら、厳密なF77コードではありません）

1つ目の答えが気に入らないので、私に反対票を投じてくれる方のための2つ目の答えは次のとおりです。どちらの言語にも、高性能コードを記述するために必要な機能があります。つまり、実装するアルゴリズム（CPU集中型？IO集中型？メモリ集中型？）、ハードウェア（単一CPU？マルチコア？分散型スーパーコンピューター？GPGPU？FPGA？）、スキル、そして最終的にはコンパイラー自体に依存します。CとFortranの両方に素晴らしいコンパイラがあります。（私はFortranコンパイラーの高度さに驚いていますが、Cコンパイラーもそうです）。

PS：Fortran GUIライブラリについて言うべき悪いことがたくさんあるので、特にライブラリを除外してよかったです。:)

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

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

とにかく、優れたプログラマーはFortranを任意の言語で作成できます。

FortanがCよりもはるかに高速であるとは聞いていませんが、場合によっては高速であると考えられます。そして重要なのは、存在する言語機能ではなく、（通常）存在しない言語機能です。

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

たとえば、次のようなstrcpyルーチンを作成したとします。

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

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

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

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

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

説明：

Cは、オペレーティングシステムを作成するために設計されました。したがって、高パフォーマンスのコードを書くのに必要以上の自由があります。一般にこれは問題ありませんが、注意深くプログラミングしないと、コードの速度が低下します。

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

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

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

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

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

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

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

FORTRANでは、多重処理のためにアルゴリズムを注意深く設計するだけで済みます。コンパイラとランタイムは、残りを処理できます。

High Performance Fortranについては少し読むことができますが、多くのデッドリンクが見つかります。並列プログラミング（OpenMP.orgなど）と、FORTRANがそれをどのようにサポートするかについて読んでおくとよいでしょう。

より高速なコードは実際には言語に依存していません。コンパイラなので、「。exe」内に結び付けられた肥大化した低速で冗長なオブジェクトコードを生成するms-vb「コンパイラ」を見ることができますが、powerBasicはあまりにも方法を生成しますより良いコード。CおよびC ++コンパイラーによって作成されたオブジェクトコードは、いくつかのフェーズ（少なくとも2つ）で生成されますが、ほとんどのFortranコンパイラーには、高レベルの最適化を含む少なくとも5つのフェーズがあるため、Fortranは常に高度に最適化されたコードを生成する機能を備えています。したがって、最後に求めるのは言語ではなくコンパイラです。私が知っている最高のコンパイラは、インテル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の方が高速である（したがって、最適化中にさらに多くの仮定を行うことができる）ことをここに言う人々もいます。しかし、これはC99（私が思う）標準以来、restrictキーワードを含めてCで扱われてきました。これは基本的にコンパイラーに、giveスコープ内ではポインターがエイリアスされないことを伝えます。さらに、Cは適切なポインター演算を可能にします。エイリアスのようなものは、パフォーマンスとリソース割り当ての点で非常に役立ちます。FORTRANの最近のバージョンでは、「適切な」ポインターの使用が可能になると思いますが。

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

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

編集：

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

http://julialang.org/benchmarks/

ほとんどの場合、Cは通常Fortranよりも優れていることがわかります（ここでも、ここで適用される以下の批評を参照してください）。他の人が述べたように、ベンチマークは、他の言語よりも1つの言語を支持するために簡単にロードできる不正確な科学です。しかし、FortranとCが同様のパフォーマンスをどのように発揮するかを説明します。

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

Fortranが開発においてより高速であるか、より便利であるかは、主に終了する必要のあるジョブに依存します。地球物理学の科学計算を行う人として、私はほとんどの計算をFortranで行いました（つまり、現代のFortran、> = F90）。

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

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

ほとんどの投稿はすでに説得力のある議論を示しているので、私はことわざの2セントを別の側面に追加します。

結局のところ、処理能力の点でFortranを速くしたり遅くしたりすることは重要ですが、Fortranで何かを開発するのに5倍の時間がかかると、

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

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

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