![プログラミング プログラミング](https://srad.jp/static/topics/programming_64.png)
2014年になってもFORTRANが選ばれる理由 70
ストーリー by hylom
まだ使われているの…… 部門より
まだ使われているの…… 部門より
あるAnonymous Coward 曰く、
本家slashdot「Why Scientists Are Still Using FORTRAN in 2014」より。
最先端の科学技術研究の分野で好んで使われる言語は2014年の今もFORTRANであることが多い。FORTRANの名は「数式翻訳」を意味する英語「FORmula TRANslation」からきているが、1950年代に考案されたこの言語の速度に勝る言語は未だ無い。FORTRANがここまで使われる理由はどこにあるのだろうか?
Ars TechnicaではFORTRANに取って代わる力のある言語としてHaskell、Clojure、Juliaが挙げられているが、/.Jerはどう見る?
slashdotではFORTRANが使われる理由として「レガシーコードであるがゆえ」「教授からFORTRANを習った学生が教授になり、そして教授となった学生がまたFORTRANを教え……という『レガシートレーニング』がゆえ」などが挙げられているが、やはりその科学技術計算に適した性質を挙げる声も多いようだ。
コンパイラの仕組みを知らない? (スコア:5, 興味深い)
こういう議論を見るたびに今はコンパイラの仕組みを知らない人が多いのだなと思う
コンパイラ作成技術が低かった太古の時代に設計されたFORTRANの特徴はメモリ割り当てが静的なこと(もちろん今は機能が拡張されているが)
当時の技術レベルでの高速なコード生成に都合の良かったこの特徴は今でも生きているし、今あるFORTRANで間に合っているのだからそれで必要十分
単にFORTRANが古いと思っているのは使い捨てのwebアプリケーションの開発者なんかだと推測するが、そのような用途に適した「近代的」プログラミング言語の特徴はゴリゴリ数値計算するのに役に立つようなものではない
そもそもプログラミング言語は階段を上るように進化して一つの万能プログラミング言語に収束するのだというような誤った考えを持っているのが問題ではないか?
Re:コンパイラの仕組みを知らない? (スコア:1)
>そもそもプログラミング言語は階段を上るように進化して一つの万能プログラミング言語に収束するのだというような誤った考えを持っているのが問題ではないか?
レヴィ・ストロースの「野生の思考」みたいな結語でワロタ(いや、批判する意図ではなくて言い得て妙すぎて
「野生の思考」がマルクス主義の発展段階論に対する強烈なアンチテーゼだったわけだが
コンピュータ業界にはヘーゲル・マルクス主義の亡霊が生き残っているのだー (ナ、ナンダッテー ΩΩ Ω
とかつぶやいてみたり。
Re: (スコア:0)
「野生の思考」がマルクス主義の発展段階論に対する強烈なアンチテーゼだったわけだが
コンピュータ業界にはヘーゲル・マルクス主義の亡霊が生き残っているのだー (ナ、ナンダッテー ΩΩ Ω
なるほど、がちがちの主義者っぽいRMS御大のGCC(GNU Compiler Collectionの方ね)のFortranはナカナカ出なかった上にしょぼいし、
資本主義の権化たるintelが出してるintel Fortranのほうがよほどまし、てのはそういう訳だったのですね(ナ、ナンダッテー ΩΩ Ω
Re: (スコア:0)
共産主義が資本主義に敗北するのは、歴史を見ても明らかではないか。
Re: (スコア:0)
マルクス主義も、プログラミング言語も、行き着く先は技術的特異点だからな
もしFORTRANで実装されたのなら、全ての高級言語FORTRANに始まり、FORTRANに終わるのか、
Re: (スコア:0)
電気仕掛けのコンピューター自体、
100年経っていないのだが。
Re: (スコア:0)
電子式は1950年あたりのようなのでざっと64年ってところですね。
それ以前は機械式だったのか。
どのみち「太古の時代に設計された」は嘘ですね。
Re:コンパイラの仕組みを知らない? (スコア:1)
太古のコンピュータとか言うからインターフェイスがドラムでドン カッ プロトコルなのかと思ったドン!
#それは太鼓
FORTRANは77?90? (スコア:3, 興味深い)
昔ちょっと書いたことがあったけど、77と90では別言語ってぐらい違ってたように思うけど、ここで言うFORTRANは77のことなのかなぁ。
77は確かにシンプルな言語仕様だったが、C言語と比較してなぜ計算が速いのかは分からなかったな。
多分、コンパイラとライブラリの成熟度の違いだろうなと今もそう思っている。
Re: (スコア:0)
ポインタによるエイリアスが発生しないのが大きい。
Re:FORTRANは77?90? (スコア:1)
へーそうなんだ。
なぜ発生しなのかは今一わからんが…、C言語でも怪しい場合はワーニングが出るはずだから
気をつけてれば今はそんなに差がないようにも思える。
Re:FORTRANは77?90? (スコア:1)
> なぜ発生しなのかは今一わからんが…、
ポインタがないんだからポインタによるエイリアシングなんか発生のしようがない
> C言語でも怪しい場合はワーニングが出るはずだから
> 気をつけてれば今はそんなに差がないようにも思える。
人間に気をつけさせても意味がなくて、コンパイラがエイリアシングが発生しないことを証明できなければならない。さもなければエイリアシングが起きていなければできたであろう最適化を諦めなければならないことがある。
具体例もあげとこうか。
http://www.emit.jp/prog/prog_opt0.html [www.emit.jp]
「コンパイラによる最適化がかからない理由」以降。
Re:FORTRANは77?90? (スコア:1)
> ポインタがないんだからポインタによるエイリアシングなんか発生のしようがない
そうだったか…もうFORTRANの事はすっかり忘れてちゃってるんだな
> 人間に気をつけさせても意味がなくて、コンパイラがエイリアシングが発生しないことを証明できなければならない。さもなければエイリアシングが起きていなければできたであろう最適化を諦めなければならないことがある。
具体例もあげとこうか。
-fstrict-aliasing を付けると(-O2以降でデフォらしい)、コンパイラはエイリアシングしてないことを前提にするから、
人間が気を付けなくてはいけなくなる。GCCは明らかに怪しい場合はワーニングを出す。
付けない場合はGCCは常にエイリアシングが発生する前提でコンパイルするはず。
Re:FORTRANは77?90? (スコア:1)
親コメの人とは別人ですが、そのエイリアシングとは別物ですよ。
C言語のstrict aliasing ruleは、(charを除く)互いに異なる型の変数が同じポインタを指さないこと。
ここで言っているのは一般的なポインタのaliasingで、複数の(同じ型を含む)ポインタが同じ実体を指さないことです。
FORTRAN(77まで)にはポインタがそもそもありません。
Fortran(90から)にはポインタがありますが、「ポインタに指されることがある変数」は明示的にコンパイラに教える必要があります。
このおかげで、配列の指す範囲の重複のありなしがコンパイラからわかりやすくなり、命令順を入れ替えても結果が変わらないかどうかを判断しやすくなり、最適化の機会が増える、という寸法です。C言語使いの人には、デフォルトがrestrictポインタ……というと雰囲気がつかみやすいかな。
Re:FORTRANは77?90? (スコア:1)
> C言語のstrict aliasing ruleは、(charを除く)互いに異なる型の変数が同じポインタを指さないこと。
> ここで言っているのは一般的なポインタのaliasingで、複数の(同じ型を含む)ポインタが同じ実体を指さないことです。
確かに調べてみると-fstrict-aliasingの最適化は互換性の無いポインタが同じアドレスを指さない事に限定してるっぽい…
ポインタが同じ型の場合は重複する可能性がある前提でコンパイルするんだろうね。
(よく考えたら、qsortとかもそうだしそんな事しょっちゅうあることだった)
Re: (スコア:0)
COMMONとかEQUIVALENCEは?
Re: (スコア:0)
C言語の対策(restrictedポインタ)がまたCらしいというかなんというか
Re: (スコア:0)
Re: (スコア:0)
C言語でも固定番地の変数使う分には同じでは?
Re: (スコア:0)
その変数を指している余計なポインタが存在しないことを保証できない点が異なる。
Re:FORTRANは77?90? (スコア:1)
今は強めの最適化を掛けると、小さい関数はコンパイラが勝手にインライン化したりするから
可読性を上げる為にも人間は積極的に関数化するべきなんだろうね。
とにかくプロファイラで計測する事が大事だね。
大文字なのか小文字なのか それが問題だ (スコア:3, 参考になる)
Fortran 90ならば新規で欠く事もあります。
特にスパコンとかで計算するときにはどうしてもライブラリとか揃ってるし、利用者も多くてコンパイラの整備も早いので。
…FORTRANの古いCodeとか正直もう見たくもありませんけど、実際にはこっちと格闘している事も多くって、可能ならば少しずつ書き直しています。
でも最近は積極的に選びません。基本的にはC++を使います。
機能的には十分な国産のフリーな流体解析ソフトが、言語がFORTRANで書かれてて扱いにくいという事を理由に、機能的にはそうでもない外国のC++でかかれたフリーな流体解析ソフトに負けつつある。HPCまわりでもそういうことが重視され始めているようです。
別に国内を腐すわけじゃないけど、外国製で使えると聞こえてくる学術系のコードはCが多いのは間違いないし。
Re:大文字なのか小文字なのか それが問題だ (スコア:3, 興味深い)
分野によるんだろうけど、自分の守備範囲だと全世界的にFORTRANが圧倒的に多いですな。
別の言語でフロントエンドが作られるってケースは多々あるけど
科学技術計算に限ってはFORTRANが読みやすいし書きやすい、自分のような若い世代でも
そう思うんだから長年使ってる人にとっては他のものは眼中にないんじゃないかな。
でもだんだん書ける人は少なくなっているみたいで他の分野の人に新規コードの作成を頼まれることが多くなった。
Re:大文字なのか小文字なのか それが問題だ (スコア:5, おもしろおかしい)
ほんとに分野によりますね。
私の同僚が昔 FFT のコードを書いていましたが、これは FORTRAN でした。一方、私は数値計算をずっとやってきましたが、共同研究先から文字列と数値がどちらもどっさり入ったデータを渡されることが多く、もう長いことそのパースに perl を使ってます。ラクダから…
ちがった。楽だから。
Re:大文字なのか小文字なのか それが問題だ (スコア:2, 参考になる)
「昔」がいつかに依りますが、数値計算アルゴリズムとサンプルコードのバイブルだったNumerical Recipe [wikipedia.org]は(もちろんFFTのコードも載っている)1989年の最初の版がFortrann77(Pascal版があったのは今wikipediaで知った)のみ、行列演算パッケージのLINPACK/LAPACKがFortranサポートのみ、で90年代は少なくとも数値計算はFortran一択だったような。
Re:大文字なのか小文字なのか それが問題だ (スコア:1)
自分もそうだけど、計算本体はFortran、プリポストはLLという人は多いのではないかな。
Re:大文字なのか小文字なのか それが問題だ (スコア:1)
FORTRANは汎用言語でなく科学技術計算向けDSLと見れば開発効率も機能も必要十分。
ただ、新たに学ぶなら他に同程度以上の開発効率と機能を持つ選択肢が複数ある。
Re: (スコア:0)
タイトルに反応するが、80年代後半の大学の計算機演習(マシンはACOS)で
全部小文字で書いていた奴がいた。
インデントも普通に付けていたのでぱっと見FORTRANに見えなかったよ。
Re: (スコア:0)
Fortan90以前は桁位置に意味のある構文だったと思うけどインデントなんか可能なの?
Re: (スコア:0)
頭6桁の意味は普通のFORTRANと同じだから、インデントと言っても
左端は空白6桁のゲタ付き。
ACOSのFORTRANが73桁以降をコメントとして見ないように
なっていたかどうかは覚えていない。
大学1年の演習なので1行が長くなることもなく、インデントを派手に
付けても72桁以内に収まっていたかもしれない。
今更、変えられないし、変える必然性がないから (スコア:3)
何百、何千あるプログラムを他の言語に書き換えるメリットはないし、
ユーザーは動けばいいのであって、言語が何かなんて興味がないし、
ということでしょう。
実際は、何十年も前に書かれたプログラムの詳細を知る人がいなくなってしまって
手を付けられないというケースも多いと思います。
後継者育成で、20万ステップ程のプログラムを若手に解析させたら1年かかりました。
FORTRANの構文理解は大して難しくありませんが、そこに書かれた内容を理解するのは容易ではありません。
それでも何をやっているのかよく分からないところが結構あって、既に退職した
開発者に聞いたら、その部分は製品が対応しなくなったので、使わないから無視してよい
と言われて脱力した事があります。
Re: (スコア:0)
2014年になっても選ばれる理由、って話なので、できたら古いのはどうなっているかではなくて、新しいものがどうなっているか知りたい。
古いコードは仕方がない/書き直す必要はないのはともかく、新しいものもまだFORTRAN使っている?
Re: (スコア:0)
Co-array Fortranの使い勝手を力説してくれた人がいますが、なかなかどうして落としどころがうまく(さすがCray)、良さげです
Re: (スコア:0)
この方に伺ったわけではないのですが、CAFの評価の一つです
http://haraken.info/_dmi/note/2010_4_9.pdf [haraken.info]
本物のプログラマは FORTRAN を使う (スコア:1)
計算が速くて数値計算のライブラリが整っているから。
特にスパコンでは。
Re: (スコア:0)
数学では滅多に仕様変更がないから、
数学で過去に最適化されたライブラリが、
「数学の定理が仕様変更されたために使えなくなりました。」
ってことはまずないでしょう。
過去の資産がそのまま使える業界なら、そのまま同じのを使うのが効率いいと思う。
Re:本物のプログラマは FORTRAN を使う (スコア:2)
> 「数学の定理が仕様変更されたために使えなくなりました。」
なんか、コレ [vector.co.jp]を貼れと言われた気がしました。
Re: (スコア:0)
> さらに、円周率が変わった場合に、プログラムの変更が容易になるという利点がある。
小学校では円周率は3で計算するってやつですか。
中学に入ったら円周率が3.14になり、高校に進んだら実はもっと桁数が多くなり、大学に入ったら実は何桁書いても表現仕切れないということを知る。
(後半はただの妄想です)
Re: (スコア:0)
円周率はπ進数で10ぴったりでしょ?
Re: (スコア:0)
というか、桁落ちなんかが容易に起きないように鍛えられてきた資産なんでしょ。
# うん年前の大学の授業の受け売り
別にいいんじゃね? (スコア:1)
使ってる方々がデメリットを感じなければ別にFORTRANでいいでしょ。
#もっとイイモノがあるよーっていう意見があってもいいけどさ。
複素数が必要なんでしょ (スコア:0)
言語仕様で複素数をサポートしてるからでしょ。
嘘です。
Re: (スコア:0)
ところで今のFortran って、行列はあるの?
Re:複素数が必要なんでしょ (スコア:1)
行列というか, 多次元配列ですね. これは昔からあります.
配列演算用組み込み関数はFortran90から標準化されています. Fortran90以降が使える環境であれば, プログラムの見通しの良さや性能向上のために, 積極的に使った方が良いでしょう. 古いプログラムでも配列演算関数を使って書き直す価値はあるかも?
Re: (スコア:0)
「行列はあるの?」の意味がわかりませんが、行列演算パッケージLAPACKは90年代からありましたが。
逆行列とか、疎の行列の演算とかは大体サポートされていたと思います。
行列を、行列として演算する(Cで表現するとfloat **matrix → float ** inv__matrixが求められる)のは困難だと思います。
翻訳に手間取りますけど、一度翻訳すれば、処理は早いと思います。そもそも、多次元配列をFortranで扱うのが(ry
# あ、まさかもしかして、これが言いたかったこと?
## 元コメの「Fortran って、行列はあるの?」
## →「《行列》って、逆行列計算などの行列演算が早い、ってことでなくて、単に多次元配列がコーディングしやすい、ってこと?」
そんな私のFortranの行列演算パッケージの知識は15年位前で止まっているので
もっと進んでいるかもしれません。
Re: (スコア:0)
ダートマスBASICのMAT文みたいなやつ。
配列ではなくプリミティブとして行列があると抽象度が増してコンパイラも楽だろうと思う。
Re: (スコア:0)
標準ライブラリ(C99) 形無し
ネタです。
Re: (スコア:0)
プレビューをよく見なかったすみません。
標準ライブラリ(C99) complex.h 形無し
ネタです。
fortranを超える言語はfortran (スコア:0)
FORTRAN77のコードいじるの本当に苦痛なんですが、あともう暫くしたらfortran2003使いから同じように思われるんだろうか、なfortran95使いです。
gcc4.9もintel fortran2015betaも出たのに今ひとつ盛り上がりに欠けてる気がする<fortran2003
理由? (スコア:0)
>1950年代に考案されたこの言語の速度に勝る言語は未だ無い。FORTRANがここまで使われる理由はどこにあるのだろうか?
直前に書いてあるそれが理由じゃないの?