Sun、新プログラミング言語Fortressをオープンソースとして公開 56
ストーリー by yoosee
しばらく前から話にはなっていましたね 部門より
しばらく前から話にはなっていましたね 部門より
Anonymous Coward曰く、
SunがJavaをオープンソースにしたことは記憶に新しいが、ZDnetの記事によると、 そのSunが今度は Fortress という新しいプログラミング言語をオープンソースソフトウェアとして公開したそうだ。
このFortressはFortranの後継として設計されており、マルチコアプロセッサを操るのが得意らしい。 fortress.sunsource.netでは言語仕様やインタープリタをダウンロードできる。
数学の記号が使える (スコア:4, 参考になる)
- Don't build the language - grow it
- Make programming notation closer to math
- Ease use of parallelism
とあります。まぁ、興味があれば資料を読んでもらえればいいのですが、処理系とか並列処理とかよく分からない私にとっては"Key Ideas"の2点目にあげられているように、いくつかの数学の記号が使えるようになる点がこの言語のうれしいところだと思っています。識別子としてギリシャ文字などを含むUnicodeが使えるのはJavaでもそうなんですが、絶対値のあの2重縦棒だとか、ΣやΠが演算子(?)として使えるようです。資料の29〜30ページにASCII文字だけで書いたコードとUnicodeを使ったコードの比較がされています。後者の方が見やすいです。
Fortranの後継とあるように、数値演算分野で好んで使われるようになるのではないかと期待しています。もうFortranのコードは見たくありません。
# パスワード忘れたのでAC
Re:数学の記号が使える (スコア:3, 興味深い)
講演の詳細 (スコア:2, 興味深い)
簡潔にまとめたメモを残されています [kmonos.net]。
一読の価値ありかと。
件の Fortress とは直接関係はないのかもしれませんが
Generalized Overloading なる話もあったようで、
あらかじめ用意された演算子のオーバーロードだけでなく、
自分で新たな演算子を定義できるようになるとかならないとか。
Unicode で書けば、視覚的にも分かり易く演算子が書けるというのは魅力かもしれません。
uxi
Re:数学の記号が使える (スコア:1)
# Fortress の仕様は読んでいません。すいません。
Re:数学の記号が使える(Slashdotに聞け!) (スコア:1)
コメントに数式を書きたくなることって無いですか?
ドットなどが大量にあるとどうしても見づらくなってしまって。
何か良い方法は無いでしょうか。
演算を行うルーチンを書く時など、処理内容を数式で直接書けると
可読性が増すと思うんですけど。
(文字で書けない事も無いけど、綺麗に書けるとうれしい)
Re:数学の記号が使える(Slashdotに聞け!) (スコア:1, 興味深い)
>コメントに数式を書きたくなることって無いですか?
>ドットなどが大量にあるとどうしても見づらくなってしまって。
>何か良い方法は無いでしょうか。
私の理想は、ひとつのソース(仮にhoge.ftxとする)を書いて、
% platex hoge.ftx
とするとhoge.dviができて数式の羅列(とコメント文)になり
% fortx hoge.ftx
とすると、その数式の処理をしてくれるバイナリができることだ(無理
Re:数学の記号が使える(Slashdotに聞け!) (スコア:2, 参考になる)
コード部分はPascal(オリジナルのWEB)かC(CWEB)に限られちゃいますが。
巧妙に潜伏したバグは心霊現象と区別が付かない。
ドキュメンテーションツール (スコア:1)
Source code documentation generator tool の一つで
ソース書き加えた定型コメントから、
HTML, RTF, LaTeX フォーマットの API マニュアル等がサクッと生成できます。
コメントには LaTeX の数式が書ける [dti.ne.jp]他、
画像の貼込 [dti.ne.jp]も可能です。
uxi
APL (スコア:0)
Re:数学の記号が使える (スコア:0)
そりゃ、入力方法は、ないわけではないけど、プログラミング言語に
使おうと思うと、入力速度が気になるわけで。日本語プログラミングが
はやらない理由もそのへんにあるのかな、と。ふだんから多種類の
文字の扱いに慣れている日本人でさえそう思うのだから、いままで
文字の数とキーボードのキーの数がほぼ等しい中で生きてきた
欧米人は、かなり戸惑うかもね。
ASCIIでも表記できるとのことだから、いやな人は使わなけりゃいい
ということなんだろうけど。
Unicode文字の入力方法 (スコア:2, 興味深い)
Unicode文字の全てを入力しようというわけではなく、限られた文字を使うだけでしょうから、そういうのを入力するインターフェースはいくらでも考えられそうです。また、欧米人のうち数学記号が必要な人ならば、決してそういうのに慣れていないわけではないと思います。数式書くのにASCII文字以外使うでしょ。
OOPSLA'06でFortressについては聞いたような... (スコア:3, 興味深い)
講演の最初ではシンプルな言語がいいんだとか言いながらできあがったFortressは偉く複雑だった印象がある。
# 日本語を理解するOOPSLA参加者というのでたどれそうなのでAC
質問です (スコア:2, 興味深い)
・インテルのCore2Duoのようなデュアルコア環境におけるプログラミング
・Sunとかが売ってる4~16個ぐらいのマルチコアを対象とした処理の分散
・大学のスパコンみたいな複数のグリッドを繋げたホモジニアスなグリッドコンピューティング
・地球シミュレーターみたいなベクトル型プロセッサを繋げたお化け
・GIMPSのようにネットワークに繋がったコンピューター資源に処理を割り振る分散コンピューティング
こーいうのって全部別々の技術で別々のプログラミング言語が使われているんですか?
それともコアの数に依存しない分散処理ができるようなプログラムを書けば
ハードウェアの違いを隠蔽してくれるような素敵な手法があったりするものなんですか?
#アスロンよりもK6レベルのコアを100個ぐらい乗っけたパソコン?が欲しい。
ごめんなさい。
Re:質問です (スコア:4, 参考になる)
プログラミング言語やライブラリと言うよりも, むしろアルゴリズムレベルで異なってくると考えた方が良いでしょう. なぜならそれぞれで性能を落とす部分が異なってくるからです. 例えば
なんてことが考えられます. デュアルコアぐらいまでだとキャッシュへのヒット率とか, それ以前の計算処理でパイプラインの乱れを減らすことに注力すればほぼ問題ありません. メモリ共有型SMPで4CPUあたりから上になってくるとコンパイラやライブラリの出来が性能の大きな部分を占めるのですが, ここでコンパイラやライブラリの癖(例えば配列のサイズとか配列へのアクセス順, 条件判断のタイミングなど)を考慮することで大きな性能差がでます. そのためアルゴリズムを局所的に最適化することが必要になります. これ以上の構成では, 計算ノード間の通信速度やネットワークトポロジにバリエーションがあっても, 基本となるのは計算をできるだけノードの中で完結させ他のノードとの通信を減らすことです. そのためには問題をいかに分割・局所化するかといったことから検討しなければなりません. こうなるとプログラミングがどうこうというレベルじゃなくなって, 事象のモデル化なんてところから再出発が必要だったりします.
Re:質問です (スコア:3, 興味深い)
Javaで書かれたOpenGL(Java 3Dだったかも)を使ったソフトウェアを実行した場合、
ソフトウェア側で複数のCPUで処理するコードを書かずとも、
Java VM側で勝手に複数のCPUに処理を分散するような設計になっていたりして、
ソフトウェアを書く側がCPUが複数あるかどうか、を気にせずとも
複数のCPUによる処理能力を得られるようになっていました。
# このため、同じマシンで実行した場合、複数のCPUの利用を考慮してない
# C++で書かれたソフトウェアよりJavaで書かれたやつの方が早かった
マシン言語にコンパイルされるプログラミング言語であれば、
ライブラリなんかを使う事で、複数のCPUの恩恵を受けられる
ソフトウェアを複数のプラットフォーム向けに書ける可能性もあるとは思います。
中間コードになるプログラミング言語であれば、
バーチャルマシンの方でそれらに対応する事が可能なので(設計として)、
複数のCPUの恩恵を受けるのに、
コードを書く側がライブラリ等さえ気にする事がない、という可能性もあると思います。
Re:質問です (スコア:1, 興味深い)
>・インテルのCore2Duoのようなデュアルコア環境におけるプログラミング
>・Sunとかが売ってる4~16個ぐらいのマルチコアを対象とした処理の分散
コレと
#それこそJ2EEのマルチスレッドとかね。
>・地球シミュレーターみたいなベクトル型プロセッサを繋げたお化け
コレと
>・大学のスパコンみたいな複数のグリッドを繋げたホモジニアスなグリッドコンピューティング
>・GIMPSのようにネットワークに繋がったコンピューター資源に処理を割り振る分散コンピューティング
コレは明らかに別だと思うけど。
最後の二つにしても、フルオーダーで作ることが少なくないのでは。
たとえ言語自体が同じだったとしても、中の仕組みは一つ一つ異なると。
Re:質問です (スコア:1)
特定の処理を多数同時に動かすことは可能ですが
異なる処理をまとめて結果を出すとなると、タスク相関を意識した作りにならざるおえません
最初から超多数のプロセスにわけて動作するように作れば
有る意味物理CPUが少なくても動かせると言う話はありますが
タスクが多数存在する為のオーバーヘッドも発生し、プログラム事態も複雑になる可能性が高く
必要以上には行われないと思います
自動化できればなーって言うのはプログラマーと経営者の夢?それとも現実?
並列化プログラミング (スコア:1)
スパコンは自動ベクトル化対応のコンパイラがサポートされてるはずです。
科学技術計算では伝統的に Fortran [kyoto-u.ac.jp] が用いられて来ましたが、
Fortran90 以降、自動ベクトル化が行い易いような拡張 [kyoto-u.ac.jp]が言語仕様に加えられています。
マルチプロセッサの場合は OpenMP [wikipedia.org] を使う事が多いようです。
商用では少なくとも インテルコンパイラー [xlsoft.com]、VisualC++ 8.0 [microsoft.com] 等が対応しています。
gcc 系では例えば GOMP [gnu.org] 等が利用できるようです。
クラスター系は MPI [wikipedia.org] や PVM [wikipedia.org] 等のライブラリが良く使われているようです。
MPI のオープンな実装としては OpenMPI [open-mpi.org] があります。
数値計算に限って言えば BLAS [netlib.org]、ATLAS [sourceforge.net]、LAPACK [netlib.org]、FFTW [fftw.org] 等、
並列化もサポートした出来合いのライブラリが既に存在するので、これらを利用するのが一般的ではないかと思います。
uxi
Re:並列化プログラミング (スコア:1)
地球シミュレータでも使われてるらしい(?)ライブラリ。
階層的地球流体スペクトルモデル集 SPMODEL [nagare.or.jp]
uxi
Re:質問です (スコア:0)
コレを [impress.co.jp]ご所望ということですね。
開発元の http://www.orionmulti.com/ [orionmulti.com]
つながらないけどどうしちゃったのかな・・・
Re:質問です (スコア:0)
識者ではないけど。
おおざっぱにいえば、言語というより、方言とライブラリの組み合わせかな。システムの構成が変われば効率の良いやり方は変わるので、多くの場合、実機とプログラムの組み合わせ毎に個別の対応が必要です。
#数値計算に限れば、言語の単純さと過去の蓄積もあって FORTRAN はまだまだ残ると思います。
>ハードウェアの違いを隠蔽してくれるような素敵な手法があったりするものなんですか?
よくわかりませんが、計算機としての基本設計からやり直す必要がありそう。
Fortran使いとして... (スコア:2, 参考になる)
やっぱり一番気になるのは、既存のFortranコードとの互換性と、コンパイラの価格かな。
FORTRAN77のコードがきちんとコンパイルできて、コンパイラがVisualStdio(アカデミック)程度の
お値段だったら、飛びついてしまうかも。
数式ライクな書き方は結構惹かれるところ。
#研究用コードは「FORTRAN77時々Fortran90、ところにより一部FORTRAN66」と混在しまくり...orz
To Do for Fortran What Java Did for C (スコア:2, 参考になる)
Fortress の開発目的は "To Do for Fortran What Java Did for C" だということでした。
というわけで、少なくとも
> 既存のFortranコードとの互換性
この点に関してはほとんど期待できないと思われます。
Re:Fortran使いとして... (スコア:1, 参考になる)
このコメント [srad.jp]にある資料を見ると、
まず、代入がPascalライクな「:=」みたいです。
というところからして、互換性は全然ダメかと思います。
Re:Fortran使いとして... (スコア:0)
並列化まわりをざっと。 (スコア:2, 参考になる)
for i ← 1:10 do print(i) end
(factorial(100), factorial(500), factorial(1000))
ふむふむ。昨今支持の広がっている、配列を並列化単位にしようという流儀ですね。
atomic式
x=0; y=0
(atomic do x+=1; y+=1 end, z=x+y)
二行目はタプルなので並列化されるけれど、
zは第一項はatomicなので z=0 か z=2 であり z=1 になることはないと。
複数の do ブロックを also で並べると並列処理される
treeSum(t : TreeLeaf) = 0
treeSum(t : TreeNode) = do
var accum := 0
do
accum += treeSum(t.left)
also do
accum += treeSum(t.right)
also do
accum += t.datum
end
accum
end
お、これは面白い。
関数・メソッド呼び出しは並列になる
myString.replace("foo", "few")
引数が並列に評価されて、myString が評価されて、replace 本体が実行されるのかな。
メソッド名は ID だけれど、関数の場合は式で、
arctan(y,x)
arctan,y,x 全てが並列に評価されるようだ。
このあたりは関数型言語や論理型言語の並列化に似てますね。
リダクションは定義された演算子が総和のみに使われているなら自動的に判定してくれるらしい
for i ← 1:10 do sum += i end
これは OpenMP とか HPF の流れか。
あとは generator とかいう生成式を定義するやつが目新しいけど、一般アプリケーションには使いどころが難しそう。
Re:並列化まわりをざっと。 (スコア:0)
この(仕様書に書いてある)例、間違ってないか?
+= がatomic operationでないと正しく動かないのだけど、仕様書に
はatomicであるとは書いておらず、かつsyntax sugarと書いてある。
for文と同様に、各スレッド
Re:並列化まわりをざっと。 (スコア:0)
勇気を持つ人ってすごいですね.私にはまねできません.
Re:並列化まわりをざっと。 (スコア:0)
するという処理があればOKだけど
そういう処理のことを Reduction といいます。
厄介払い (スコア:1, 興味深い)
Re:厄介払い (スコア:2, 興味深い)
オープンソースにしたからといってコストが0になるわけでもなく、Sunにはお蔵入りという選択肢もあったはず。
徐々にですが、オープンソース化が企業の戦略の一つとして定着してきているのかなと思います。
Re:厄介払い (スコア:1, おもしろおかしい)
SUNがなにかをオープンソースにすると、それはオープンにしろよぉ圧力に負けたりオープンにしないと見ても貰えなかったりが原因だったり…
Re:厄介払い (スコア:3, すばらしい洞察)
見方が最近多いような気がするんですが…
sunrpc とか、1989年頃、すなわち Linux とか生まれる前からオープンで、
glibc にもそれがそのまま含まれてたりするわけで、個人的には全く逆の
印象ですねえ。なんというか、IBM がオープンになりだしたのはつい最近で、
だからこそそれが目だっているだけというか。
Sun は、そのコア技術 (Solaris とか Java) とかオープンになるわけでしょう。
Java が GPL になるのはこれからですが、それ以前もライセンスに同意すれば、
誰でもソースコードを読める状況にあったわけです。
これに対して、IBM は AIX も DB2 もクローズで、ソースアクセスもできない
わけで…
別にどちらの会社も、ビジネス的に有利だと思えばオープンにするが、そうで
ない場合にはクローズという姿勢に変わりはなくて、単に宣伝がうまいか下手か
くらいしか違いがないんじゃないでしょうか。
やっほーフォートランらんらん (スコア:1, おもしろおかしい)
Re:やっほーフォートランらんらん (スコア:2, 参考になる)
> この歌は、国際会議で日本代表が歌ったこともある、由緒正しいものです。 :-P
> [参考文献:“詳解 Fortran 90", bit 別冊,共立, 1994, 訳者あとがき]
とのことだそうです。
Yahoo! FORTRAN LAN RUN (スコア:1, おもしろおかしい)
Re:やっほーフォートランらんらん (スコア:1)
pure pure lisp
気持ちはt
とでも歌っておきますか。
Lispなら (スコア:1)
♪静かな湖畔の森の陰から、もう起きちゃいかがと括弧が鳴く♪
♪括弧、括弧、括弧括弧括弧♪
じゃないかしら、とか。
# 1行目のカッコをどう表すか迷いつつ、ID。
Re:Lispなら (スコア:1)
>♪括弧、括弧、括弧括弧括弧♪
それではエラーじゃないかな? と歌わないと。
そこで切っちゃ駄目だそうです (スコア:1)
c.f. Ratfor [wikipedia.org]
Re:やっほーフォートランらんらん (スコア:0)
「ふぉーたん? アレゲな名前のわりには今まで聞いた事無いな」
等と思った私が居ます。
マルチコアプロセッサを扱うのが得意 (スコア:1, 興味深い)
z=f(x)+g(y)
と記述したときに自動的にf(x)とg(y)を並行処理にしてくれたりするとか。
とすると、関数型言語に近くなっているのでしょうか。
なかなか面白そうかも。
早く日本語の紹介記事が出ないかな。
Re:マルチコアプロセッサを扱うのが得意 (スコア:1, 興味深い)
言語仕様的に、自動並列化されても意味的に変わらないものになってさえいれば、
自動並列化の有無は、コンパイラ(or ランタイム)の実装次第でしょう。
まあ、実際、上の式ぐらいの自動並列化を備えた処理系なら
期待して構わないと思います。
ちなみに並列化と関数型言語云々は全然関係ありません。
Re:マルチコアプロセッサを扱うのが得意 (スコア:0)
というか FORTRAN の唯一の拠り所(?)
ってそれは言語じゃなくてコンパイラの話だろうと
>>z=f(x)+g(y)
>>と記述したときに自動的にf(x)とg(y)を並行処理にしてくれたりするとか。
こっちは関数 f(x) と g(y) を別スレッド/別CPUで(?)並列に計算して実時間を圧縮してくれってことだろうな
Re:マルチコアプロセッサを扱うのが得意 (スコア:0)
ポトリス (スコア:0)
…で (スコア:0)
Re:…で (スコア:1)
Rats!ステ (スコア:0)
ヒープ消費量がO(n)なパーザRats! [nyu.edu]はいらん。
んで、FORTRANのように大規模なものが組まれるようになった時、
Fortressではどんなパージングするかっつーことが問題ですが。
まさかyaccではできないからpackrat選んだんだろうし…
セブン? (スコア:0, オフトピック)
# ごめんナイトウィザードなら持ってるんだが