トップ 最新 追記

U-memo

2006|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|08|
2009|08|10|
2010|02|03|
2011|11|12|
2012|04|
2016|02|
All= / Today= / Yesterday=

2007-01-09 [長年日記]

_ [tDiary] tDiary 2.0.4

上げたと思ったらまたすぐに脆弱性対応で上がってましたか。 そのうち入れよう。

_ [プロセッサ] map と reduce?

単にmapとreduceを加えれば良いのでは?と思ってしまった。 mapとreduceと後はsortのような配列演算ライブラリを整備するだけで、並列化可能な部分の99%は自動的に並列化される。Rubyでも簡単に対応できる。あとはiteratorにvariantかpragmaを入れて評価順を不定にし、破壊的変更を不可にするのを加えると良いかも。

map はともかく reduce は適用する関数が交換可能であるとき、 つまり順不同に適用しても同じ結果が得られることが保証できる場合でないと並列化は出来ないですよね。

# たとえば list.reduce( fun(x y){x-y} ) (構文適当) だとうまくいかない。

あと、そういうのとは次元の違う話として、 「並列化が出来る」ことと「並列化して速くなる(結果が早く得られる)」ことは別の次元の話だということに注意が必要。

list.map( fun(x){x+1} ) なんて単純なものを並列ジョブにすると その並列化のコストの方が割高になることがほとんどだろう (リストの分割結合とプロセッサコア間通信コストを考えただけでも)。 もっとも、巨大リストが操作対象のときは、 リストを数個に分割してやれば速くなるだろうから、 いつどういう並列化をするのかトレードオフの話である。 逆に関数が重ければ、 listの要素が数個であっても分割する価値があることもあるだろう。

# つまり実行時に動的分配する位の芸当は出来ないと意味をなさない

だが、現状はこの程度の事も、専用コンピュータを使うか、 OpenMP, MPI のような並列化ライブラリを駆使するか、 自動並列化コンパイラに頼るにしても手軽にはまともな性能はでない。

  • (脱線)

自動並列コンパイラは(C,Fortran あたりなら)既にあります。 そういう用途が少ないのでプロ向けにしか出回ってませんが 最近は Intel も Core 路線で icc コンパイラが 対応してきているみたいですね。

逆にいうと、map だけが唯一並列化する手段でもなくて、 イテレータであっても順序依存性を勝手に判断して 並列化をコンパイラがやってくれる、というのも、 既に現実の世界。

# その道のプロはあまり使わないだろうけれど

  • (さらに脱線)

現状ではプロセッサコア(CPU) と OS の組み合わせによる並列化は、 専用ライブラリや専用ハードを除けば プロセス並列/スレッド並列くらいしか現実味がない。

専門家が使うのならともかく、一般民が使える並列環境ともなると、 タスクスイッチや処理中断程度は普通に耐えるような OS 環境でないと 使ってもらえない。

つまり多重並列している最中にタスクスイッチして全並列情報を 退避させることは普通にできないと困るわけで、 今のところスレッド並列(と同等レベルの事)までしか出来なさげ。 それより細かいと一気にハードウェアレベルに落ちて アウトオブオーダ実行とかになってしまう。

  • (それはさておき)

話がそれすぎてわけが分からなくなったので今日はここまで。

_ [雑記] trackback

受け付けられるようにしておいた方がいいのかねぇ。 SPAM 恐いんだけど (コメントSPAM もそうだが)...


2007-01-13 [長年日記]

_ [tDiary] tDiary 2.0.4 入れた

ついでに makeRSS, trackback 有効。

トラックバックの有効の仕方はこのへん。

makerss は index.rdf の処遇だけ忘れなければよい。

あと antispam も導入した。


2007-01-14 [長年日記]

_ [OCaml] OCaml の嫌いなところ

yoriyuki さんが OCamlerを止めてデファクトスタンダードを愛するようになった なんて書いている。

デファクトスタンダードがどれだという話はあるけれど。

 1.   言語の進歩が止まっている

これは一長一短か。後方互換を無視して開発されるのよりはましだ。

進歩が止まっているというより、日本国内だけをとれば コミュニティが停滞しているほうが深刻だろう。

 2. ユーザーが少ない

これは OCaml に限ったことではないけどマイナー言語のデフレスパイラルですな。フランス本国ではどれくらいのユーザーがいるのか知らないけれど、なかなか世界的言語にはなれないですな。

 3. 標準ライブラリが貧弱かついい加減

禿同。 Sys にあるのか Unix にあるのか探すだけで苦痛だ。

 4. 複数ファイルに分かれたプログラムの扱いがインタープリタとコンパイラで違っている

たしかにいきなりはまるので共感するけれど、 真に実感するほどには使っていない。 既存ライブラリは toplevel を再作成することで逃れられるけど、 中〜大規模プロジェクトでは苦痛かもしれない。

 5. 高階関数はもはや大抵の言語で使えるようになった

C で使えない、かつ、C 並みの速度の言語に乏しいのでこれは否かな。 手続きベースなら D 使えということかもしれないが、 関数的言語ベースでないと関数型特有のテクニックは なかなか身につかないと思う。

速度にこだわるのは、10倍も遅くていい状況なら Perl 使うからです。 Perl との暗黙の比較があるのさ。

 6. 静的型チェックやパターンマッチが有効なのは一部の場合だけ

未体験なので良く分からん。

 7. オーバーローディングがない

禿同…ってこれに同意すると + と +. から区別される OCaml なんぞ使うなという結論になる気はするが。

 8. 構文に問題が多い

優先順位については、 C 以来バッドノウハウで回避する癖がついてるのであまり気にならない。 そもそもデフォルトの優先順位を余り覚えないので括弧は多めになる。

それよりも、mod だよ mod。int のときは中置で作用するのに Nums とかでは(mod_num) 中置ではなく前置のところ。

 9. ビルドにMakeを使う

これは OCaml の問題ではない気が。 GODI みたいなのはダメとかいう話かしら?知らないけれど。

10. 開発ツールの不備

よくわからん。

11. Emacsモードのインデントが気に入らない

tuareg-mode でも気に入らない。デフォルトからいじれば望みのものが 得られるのかどうかまだ調べてないんだけど、 そもそもデフォルトでプログラミングガイドラインと異なる インデントになるのがどうも。

12. OOは本質的に動的で静的型付けになじまない(印象論)

OO 使わないからどうでもいい。

 

これらに付け加えるのかどうか分からないけど不満を書き足しておこう。

  • リファレンスマニュアルがいや杉

「言語仕様」「処理系の実装仕様」「チュートリアル」が混在していて、 かつ仕様未定義なのかどうか境界条件がさっぱり分からないことも しばしば。undocumented な仕様もあるようだし。 (コンパイラオプションのヘルプに堂々とそう出てくるくらいだからなぁ)

  • CPAN みたいなのがない。

標準ライブラリ以外が統一されてなくてばらばらに開発されている印象。 Humps で参照しろと いうことなのだろうけれど。

_ [OCaml] なぜ OCaml を選んだのか

前提として、C, Perl 使いである私として、これらで足りる領域は コレで十分、というのがある。

古の BASIC、アセンブリ言語を除けばかじったことがあるのは

  • FORTRAN77 (大学の実習でやった程度)
  • C (事実上コレからはなれられない)
  • Perl (文字列処理はコレしか!)
  • Java (出たての頃にかじってみたがあの堅苦しさがいや)
  • C++ (STL の挙動がわかりにくくて事実上挫折)
  • PL/I (会社で仕方なく)
  • Ruby (微妙に堅苦しいのがどうも)

くらいかな。Perl でなくて十分なときは Bourne shell スクリプトですが。

で、C, Perl 以外は身によくつくことはなかったわけで、 OCaml の何でもアリなところに惹かれたのは事実。

  • 関数型、命令型、OO どれでもこい (逃げ道があるのは重要)
  • ネイティブコードが速い (とはいえ最近は Haskell-GHC もかなり上位だ)
  • 中置記法で書ける (Lisp 系はこの一点で選外になる)
  • Bigint がある (これは趣味の都合)

思いついたらまた付け足す。


2007-01-15 [長年日記]

_ [雑記] そういえば

某@niftyのページは放置プレイのままだなぁ。 ってかアクセス方法も忘れたような。

移転通知くらい書いておくにも困ったな。