- kazunori_279
- 2972
- 0
- 4
- 0
I/Oというか通信ネックになりそうなのは間違いなくて、既存の命令型の延長で組んだプログラムを何とか最適化して…と言う方向はたぶん厳しい
2010-05-03 16:33:40何とはなしにいったけど、タイムライン的な時間軸に対してフーリエ変換とかウェーブレット変換的なものを考えると面白いかもしれんね
2010-05-03 16:39:04@ashigeru 計算モデルというか、数値計算手法に制約がついちゃうイメージですかね?個人的には、mapをなにかの計算に見立てるとすると、粒度の問題は大きくなりそうな印象です。でも、なにで計算するかって重要ですか?
2010-05-03 16:49:09@marblejenka もっとも単純な話では、ある数列を別の数列に変換する時に、値を別個に変換できるのかできないのかってところですかね。常にanの解析にan-1が必要だとちょっとどうやるのかが思いついてないというのか。
2010-05-03 16:51:42@ashigeru ああ、そういうことですか。mapの粒度をまたがる計算は制限されそうですね。金融商品だと、早期償還条件付き商品とかはキャッシュフローの粒度で評価できないので、hadoop使うとすると悩みどころになるなーという感じです。
2010-05-03 16:57:51@marblejenka software pipeliningとかそっち系の最適化を使うと行けるのかなーとも思いつつ、あんまり特徴に合ってないからいろいろと事例研究に移ろうかなとも思い始めてます
2010-05-03 17:00:02てか、ベクトルマシンのプロセッサに関する最適化コンパイラを習っていたのが意外にもこんなところで役に立つ(?)とはよく分からないもんだ
2010-05-03 17:01:26@ashigeru おー、事例があるのか?というところはありますが。。hadoopのサンプルで円周率をモンテカルロで計算してるのはありましたが、事前にパスの分だけlineを生成してて、こりゃだめだ、というのはありました。きっともっと賢いやりかたもできるのでしょうけど。。。
2010-05-03 17:07:00@marblejenka モンテカルロは集約に結合法則がある計算を使うので向いてると思います。問題はそうじゃない計算
2010-05-03 17:08:58@marblejenka ループを展開してMRにあてはめられんのかいなとか一瞬考えちゃった。。つ、釣られてなんかいないからね!
2010-05-03 17:10:45@ashigeru いや、僕がためした範囲では、モンテカルロの1パスをmapにするのは用途が思いつかない程度には遅かったです。なので、計算を分解するよりも1mapに相当するそれなりに大きい計算をやるのが妥当なのかなと思ってます。これも用途によっちゃうんでしょうけど。
2010-05-03 17:16:14@marblejenka なる。象本的には1Mapで1分くらいがいいんじゃねとのこと。もちろん状況次第と思いますが
2010-05-03 17:18:53@kazunori_279 そんな感じなんじゃないですかね。むしろ、@ashigeru氏が考えてそうな複雑なことって出来るのかなー、という感じです。map side joinとかreduce side joinとか?
2010-05-03 17:24:37@marblejenka まぁ、それはutilizationを上げるための指標なので文脈によって変わるものではあると思います。とりあえずCPUネックにするのは非常に難しいw
2010-05-03 17:27:46おそらく、力技で複雑な計算するんじゃなくて、多次元トーラスに近い形でオリジナルのデータを分散レプリケーションさせて、ローカリティを多段階にする必要はあると思う
2010-05-03 17:30:29通常の業務処理をバラしていろんなパターンでやってますが、reduceがボトルネックになるので~。というかMapが簡単にスケールするので、できるだけMapにガシガシ処理させて、CPUネックになるようにやってます~。
2010-05-03 17:31:46@ashigeru なるほど。でも単にmapを1モンテカルロにするとかだったら、そんぐらいにはなりそうですね。そんなに時間がかかると逆にだめっぽいというのはありますが。。
2010-05-03 17:33:26