パスワードを忘れた? アカウント作成
14395 story

Sun、新プログラミング言語Fortressをオープンソースとして公開 56

ストーリー by yoosee
しばらく前から話にはなっていましたね 部門より

Anonymous Coward曰く、

SunがJavaをオープンソースにしたことは記憶に新しいが、ZDnetの記事によると、 そのSunが今度は Fortress という新しいプログラミング言語をオープンソースソフトウェアとして公開したそうだ。
このFortressはFortranの後継として設計されており、マルチコアプロセッサを操るのが得意らしい。 fortress.sunsource.netでは言語仕様やインタープリタをダウンロードできる。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2007年01月16日 1時58分 (#1092288)
    Guy Steeleが来日したときにFortressに関する講演を聞いたことがあります(そのときに配られた資料 [sun.com])。この資料の4ページ目には"Key Ideas"として、

    - 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
    • by Anonymous Coward on 2007年01月16日 9時43分 (#1092359)
      Fortressの重要なアイディアとして,1点目の
      • Don't build the language - grow it
      も見逃せないと思います.
      これは,言語のコアはなるべく強力だけど小さいものにしておいて, ライブラリで頑張るという思想だと思います. (Schemeに通じるものがありますよね)

      豊富な数学的記号の意味をライブラリとして定義することによって, 言語のコアは小さくしたまま,リッチな言語に成長させていくことができる, ということです.
      あと,C++の演算子における多重定義の問題点も,演算記号の少なさが 原因の一つだったんだから,豊富な数学記号を用意してやれば この問題は解決できる.みたいな.
      親コメント
    • 講演の詳細 (スコア:2, 興味深い)

      by uxi (5376) on 2007年01月17日 1時42分 (#1092959)
      「caldix」の作者K.INABAさん [impress.co.jp]が、その講演を聞いておられたようで
      簡潔にまとめたメモを残されています [kmonos.net]。
      一読の価値ありかと。

      件の Fortress とは直接関係はないのかもしれませんが
      Generalized Overloading なる話もあったようで、
      あらかじめ用意された演算子のオーバーロードだけでなく、
      自分で新たな演算子を定義できるようになるとかならないとか。
      Unicode で書けば、視覚的にも分かり易く演算子が書けるというのは魅力かもしれません。
      --
      uxi
      親コメント
    • 数式処理とマルチコアプロセッサ向けならAPLの方が向いている気がする。
      # Fortress の仕様は読んでいません。すいません。
      親コメント
    • 変数や演算子などに数学記号が使えるのも非常に良いのですが、
      コメントに数式を書きたくなることって無いですか?
      ドットなどが大量にあるとどうしても見づらくなってしまって。
      何か良い方法は無いでしょうか。

      演算を行うルーチンを書く時など、処理内容を数式で直接書けると
      可読性が増すと思うんですけど。
      (文字で書けない事も無いけど、綺麗に書けるとうれしい)
      親コメント
    • by Anonymous Coward
      UnicodeにはAPL [wikipedia.org]記号が含まれているからFortressもAPLをサブセットに含んでいたりして。
    • Unicode文字って、どうやって入力するんだろう。

      そりゃ、入力方法は、ないわけではないけど、プログラミング言語に
      使おうと思うと、入力速度が気になるわけで。日本語プログラミングが
      はやらない理由もそのへんにあるのかな、と。ふだんから多種類の
      文字の扱いに慣れている日本人でさえそう思うのだから、いままで
      文字の数とキーボードのキーの数がほぼ等しい中で生きてきた
      欧米人は、かなり戸惑うかもね。

      ASCIIでも表記できるとのことだから、いやな人は使わなけりゃいい
      ということなんだろうけど。
      • by Anonymous Coward on 2007年01月16日 10時08分 (#1092376)
        そういう心配もあったのですが、いまやEclipseといったIDEが当たり前になってきていて、コード片をショートカットキーで入力できるようになっているので、Fortress向けのEclipseプラグインとかできるようになれば問題なさそうです。あるいは、Fortressの場合はUnicode文字を使った表現と等価な表現をASCII文字で書けるっぽいので、もしそうだとしたら、ASCII文字で入力したものがインタラクティブにUnicode文字に変換されるようになると面白いですね。別に入力するぶんには、"sigma"とか"||"とか打つぐらいなんてことはないです。

        Unicode文字の全てを入力しようというわけではなく、限られた文字を使うだけでしょうから、そういうのを入力するインターフェースはいくらでも考えられそうです。また、欧米人のうち数学記号が必要な人ならば、決してそういうのに慣れていないわけではないと思います。数式書くのにASCII文字以外使うでしょ。
        親コメント
  • by Anonymous Coward on 2007年01月16日 1時22分 (#1092271)
    OOPSLA'06にて、Fortressの講演を聴いただけにちょっとタイムリーすぎてびっくりした。
    講演の最初ではシンプルな言語がいいんだとか言いながらできあがったFortressは偉く複雑だった印象がある。

    # 日本語を理解するOOPSLA参加者というのでたどれそうなのでAC
  • 質問です (スコア:2, 興味深い)

    by AnomalousCoward (32957) on 2007年01月16日 1時24分 (#1092272) 日記
    識者の方にお聞きしたいんですが、
    ・インテルのCore2Duoのようなデュアルコア環境におけるプログラミング
    ・Sunとかが売ってる4~16個ぐらいのマルチコアを対象とした処理の分散
    ・大学のスパコンみたいな複数のグリッドを繋げたホモジニアスなグリッドコンピューティング
    ・地球シミュレーターみたいなベクトル型プロセッサを繋げたお化け
    ・GIMPSのようにネットワークに繋がったコンピューター資源に処理を割り振る分散コンピューティング
    こーいうのって全部別々の技術で別々のプログラミング言語が使われているんですか?
    それともコアの数に依存しない分散処理ができるようなプログラムを書けば
    ハードウェアの違いを隠蔽してくれるような素敵な手法があったりするものなんですか?

    #アスロンよりもK6レベルのコアを100個ぐらい乗っけたパソコン?が欲しい。
    --
    ごめんなさい。
    • Re:質問です (スコア:4, 参考になる)

      by SteppingWind (2654) on 2007年01月16日 12時56分 (#1092473)

      プログラミング言語やライブラリと言うよりも, むしろアルゴリズムレベルで異なってくると考えた方が良いでしょう. なぜならそれぞれで性能を落とす部分が異なってくるからです. 例えば

      • キャッシュと主メモリの速度差によりランダムアクセス性能が劣化する
      • 別CPUによりデータが書き換えられることにより, データキャッシュが無効化される
      • メモリの同一領域にアクセスが重なることで開放待ちが発生する
      • 計算ノード間でのデータ通信が律速になる

      なんてことが考えられます. デュアルコアぐらいまでだとキャッシュへのヒット率とか, それ以前の計算処理でパイプラインの乱れを減らすことに注力すればほぼ問題ありません. メモリ共有型SMPで4CPUあたりから上になってくるとコンパイラやライブラリの出来が性能の大きな部分を占めるのですが, ここでコンパイラやライブラリの癖(例えば配列のサイズとか配列へのアクセス順, 条件判断のタイミングなど)を考慮することで大きな性能差がでます. そのためアルゴリズムを局所的に最適化することが必要になります. これ以上の構成では, 計算ノード間の通信速度やネットワークトポロジにバリエーションがあっても, 基本となるのは計算をできるだけノードの中で完結させ他のノードとの通信を減らすことです. そのためには問題をいかに分割・局所化するかといったことから検討しなければなりません. こうなるとプログラミングがどうこうというレベルじゃなくなって, 事象のモデル化なんてところから再出発が必要だったりします.

      親コメント
    • Re:質問です (スコア:3, 興味深い)

      by Anonymous Coward on 2007年01月16日 4時27分 (#1092313)
      SGIのスーパーコンピューター(といっても当時CPUが8個くらいのやつ)だと、
      Javaで書かれたOpenGL(Java 3Dだったかも)を使ったソフトウェアを実行した場合、
      ソフトウェア側で複数のCPUで処理するコードを書かずとも、
      Java VM側で勝手に複数のCPUに処理を分散するような設計になっていたりして、
      ソフトウェアを書く側がCPUが複数あるかどうか、を気にせずとも
      複数のCPUによる処理能力を得られるようになっていました。

      # このため、同じマシンで実行した場合、複数のCPUの利用を考慮してない
      # C++で書かれたソフトウェアよりJavaで書かれたやつの方が早かった

      マシン言語にコンパイルされるプログラミング言語であれば、
      ライブラリなんかを使う事で、複数のCPUの恩恵を受けられる
      ソフトウェアを複数のプラットフォーム向けに書ける可能性もあるとは思います。

      中間コードになるプログラミング言語であれば、
      バーチャルマシンの方でそれらに対応する事が可能なので(設計として)、
      複数のCPUの恩恵を受けるのに、
      コードを書く側がライブラリ等さえ気にする事がない、という可能性もあると思います。
      親コメント
    • Re:質問です (スコア:1, 興味深い)

      by Anonymous Coward on 2007年01月16日 2時17分 (#1092295)
      指揮車というほどじゃないけれど、

      >・インテルのCore2Duoのようなデュアルコア環境におけるプログラミング
      >・Sunとかが売ってる4~16個ぐらいのマルチコアを対象とした処理の分散
      コレと
      #それこそJ2EEのマルチスレッドとかね。

      >・地球シミュレーターみたいなベクトル型プロセッサを繋げたお化け
      コレと

      >・大学のスパコンみたいな複数のグリッドを繋げたホモジニアスなグリッドコンピューティング
      >・GIMPSのようにネットワークに繋がったコンピューター資源に処理を割り振る分散コンピューティング
      コレは明らかに別だと思うけど。

      最後の二つにしても、フルオーダーで作ることが少なくないのでは。
      たとえ言語自体が同じだったとしても、中の仕組みは一つ一つ異なると。
      親コメント
    • by mocchino (13752) on 2007年01月16日 11時10分 (#1092402)
      厳密に見ればタスク相関が有る限り完全には解消出来ないでしょう
      特定の処理を多数同時に動かすことは可能ですが
      異なる処理をまとめて結果を出すとなると、タスク相関を意識した作りにならざるおえません

      最初から超多数のプロセスにわけて動作するように作れば
      有る意味物理CPUが少なくても動かせると言う話はありますが
      タスクが多数存在する為のオーバーヘッドも発生し、プログラム事態も複雑になる可能性が高く
      必要以上には行われないと思います

      自動化できればなーって言うのはプログラマーと経営者の夢?それとも現実?
      親コメント
    • by uxi (5376) on 2007年01月17日 2時59分 (#1092980)
      聞きかじった限りでは、
      スパコンは自動ベクトル化対応のコンパイラがサポートされてるはずです。
      科学技術計算では伝統的に 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
      親コメント
    • by Anonymous Coward
      >#アスロンよりもK6レベルのコアを100個ぐらい乗っけたパソコン?が欲しい。
      コレを [impress.co.jp]ご所望ということですね。
      開発元の http://www.orionmulti.com/ [orionmulti.com]
      つながらないけどどうしちゃったのかな・・・
    • by Anonymous Coward
      >こーいうのって全部別々の技術で別々のプログラミング言語が使われているんですか?
      識者ではないけど。
      おおざっぱにいえば、言語というより、方言とライブラリの組み合わせかな。システムの構成が変われば効率の良いやり方は変わるので、多くの場合、実機とプログラムの組み合わせ毎に個別の対応が必要です。
      #数値計算に限れば、言語の単純さと過去の蓄積もあって FORTRAN はまだまだ残ると思います。

      >ハードウェアの違いを隠蔽してくれるような素敵な手法があったりするものなんですか?
      よくわかりませんが、計算機としての基本設計からやり直す必要がありそう。
  • by born_in_9.11 (32056) on 2007年01月16日 3時03分 (#1092309) 日記

    やっぱり一番気になるのは、既存のFortranコードとの互換性と、コンパイラの価格かな。
    FORTRAN77のコードがきちんとコンパイルできて、コンパイラがVisualStdio(アカデミック)程度の
    お値段だったら、飛びついてしまうかも。

    数式ライクな書き方は結構惹かれるところ。

    #研究用コードは「FORTRAN77時々Fortran90、ところにより一部FORTRAN66」と混在しまくり...orz

  • by Anonymous Coward on 2007年01月16日 15時11分 (#1092562)
    forループやタプルの評価は自動的に並列になる。
        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 とかいう生成式を定義するやつが目新しいけど、一般アプリケーションには使いどころが難しそう。

    • 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

      この(仕様書に書いてある)例、間違ってないか?

      += がatomic operationでないと正しく動かないのだけど、仕様書に
      はatomicであるとは書いておらず、かつsyntax sugarと書いてある。

      for文と同様に、各スレッド

      • 仕様書をちょっと見ただけで,バグを見つけたと公言できる
        勇気を持つ人ってすごいですね.私にはまねできません.

        13.15.1 Reduction Variables
        (中略)
        We say that a variable l is a reduction variable reduced using the reduction operator ⊙ for a particular for loop if it satisfies the following conditions:

        • Every assignment to l within the loop body uses the same reduction operator ⊙, and the value of l is not otherwise read or written.
        • The variable l is not a free variable of a fn expression or a method in an object expression whic
      • >for文と同様に、各スレッド毎にローカルなaccumを確保してjoin時に値を合計
        するという処理があればOKだけど

        そういう処理のことを Reduction といいます。
  • 厄介払い (スコア:1, 興味深い)

    by Anonymous Coward on 2007年01月16日 0時55分 (#1092262)
    SunはHPCS Phase 3から脱落した [slashdot.org]から、投資する戦略的理由がなくなったのでしょう。
    • Re:厄介払い (スコア:2, 興味深い)

      by Anonymous Coward on 2007年01月16日 6時58分 (#1092328)
      逆に言うとオープンソースにする戦略的理由が出来たということでしょう。
      オープンソースにしたからといってコストが0になるわけでもなく、Sunにはお蔵入りという選択肢もあったはず。
      徐々にですが、オープンソース化が企業の戦略の一つとして定着してきているのかなと思います。
      親コメント
      • Re:厄介払い (スコア:1, おもしろおかしい)

        by Anonymous Coward on 2007年01月16日 10時43分 (#1092387)
        IBMがなにかをオープンソースにすると、それは競合他社を潰すための武器だったりするわけだが、
        SUNがなにかをオープンソースにすると、それはオープンにしろよぉ圧力に負けたりオープンにしないと見ても貰えなかったりが原因だったり…
        親コメント
        • Re:厄介払い (スコア:3, すばらしい洞察)

          by Anonymous Coward on 2007年01月16日 18時01分 (#1092652)
          なんか、こういう IBM == オープン、Sun == いやいやオープンみたいな
          見方が最近多いような気がするんですが…

          sunrpc とか、1989年頃、すなわち Linux とか生まれる前からオープンで、
          glibc にもそれがそのまま含まれてたりするわけで、個人的には全く逆の
          印象ですねえ。なんというか、IBM がオープンになりだしたのはつい最近で、
          だからこそそれが目だっているだけというか。

          Sun は、そのコア技術 (Solaris とか Java) とかオープンになるわけでしょう。
          Java が GPL になるのはこれからですが、それ以前もライセンスに同意すれば、
          誰でもソースコードを読める状況にあったわけです。
          これに対して、IBM は AIX も DB2 もクローズで、ソースアクセスもできない
          わけで…

          別にどちらの会社も、ビジネス的に有利だと思えばオープンにするが、そうで
          ない場合にはクローズという姿勢に変わりはなくて、単に宣伝がうまいか下手か
          くらいしか違いがないんじゃないでしょうか。
          親コメント
  • by Anonymous Coward on 2007年01月16日 1時32分 (#1092276)
    誰かが言わねばなるまい(ACだけど)
  • by Anonymous Coward on 2007年01月16日 2時44分 (#1092304)
    言語仕様も何も見ずに想像で書きますが、「マルチコアプロセッサを扱うのが得意」は「並行処理を記述するのが得意」ということでしょうかね。
    z=f(x)+g(y)
    と記述したときに自動的にf(x)とg(y)を並行処理にしてくれたりするとか。
    とすると、関数型言語に近くなっているのでしょうか。
    なかなか面白そうかも。
    早く日本語の紹介記事が出ないかな。
    • by Anonymous Coward on 2007年01月16日 11時21分 (#1092410)
      x, y, zがベクトルなら、自動並列化はFortranの並列化ではわりとありふれた話です。

      言語仕様的に、自動並列化されても意味的に変わらないものになってさえいれば、
      自動並列化の有無は、コンパイラ(or ランタイム)の実装次第でしょう。
      まあ、実際、上の式ぐらいの自動並列化を備えた処理系なら
      期待して構わないと思います。

      ちなみに並列化と関数型言語云々は全然関係ありません。
      親コメント
      • >x, y, zがベクトルなら、自動並列化はFortranの並列化ではわりとありふれた話です。

        というか FORTRAN の唯一の拠り所(?)
        ってそれは言語じゃなくてコンパイラの話だろうと

        >>z=f(x)+g(y)
        >>と記述したときに自動的にf(x)とg(y)を並行処理にしてくれたりするとか。

        こっちは関数 f(x) と g(y) を別スレッド/別CPUで(?)並列に計算して実時間を圧縮してくれってことだろうな
    • 人間の手で明示的に指示してよいのなら、Occam [wikipedia.org] という言語がありました。INMOS Transterpreter [wikipedia.org] 共々お亡くなりになったようなものですけど:-p

  • by Anonymous Coward on 2007年01月16日 1時12分 (#1092267)
    一瞬ポトリスがオープンソースになったのかt
  • by Anonymous Coward on 2007年01月16日 8時10分 (#1092337)
    要塞になってますが、何の略語なんでしょう。FAQにも書いてなさそうなんですが。
  • by Anonymous Coward on 2007年01月16日 8時39分 (#1092341)
    いくら参照実装とはいっても、アルゴリズム自体が半端なく実用的じゃない。
    ヒープ消費量がO(n)なパーザRats! [nyu.edu]はいらん。

    んで、FORTRANのように大規模なものが組まれるようになった時、
    Fortressではどんなパージングするかっつーことが問題ですが。
    まさかyaccではできないからpackrat選んだんだろうし…
  • セブン? (スコア:0, オフトピック)

    by ryouki7000 (10944) <{ryouki7000} {at} {gmail.com}> on 2007年01月16日 9時51分 (#1092366) 日記
    何のTRPGシステム [wikipedia.org]がソース公開されるって?

    # ごめんナイトウィザードなら持ってるんだが
typodupeerror

開いた括弧は必ず閉じる -- あるプログラマー

読み込み中...