トップ «前の日記(2010-01-31) 最新 次の日記(2010-02-06)» 編集

はじめてのにき

ここの位置付け

2004|11|
2005|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|12|
2018|01|02|03|04|05|06|07|08|09|10|11|12|
2019|01|02|03|04|05|

ToDo:


2010-02-01

_ 並カン

何やら色々楽しかったものの宿題も増える感じだった。

  • メーヤウが店の雰囲気かわってからやはりおいしくなくなってるような…
  • 並列プログラムの作り方という本が良いらしい
  • Molatomium の詳説とかはなかった
  • id:goyoki さんの FPGA 系の。やっぱ楽しそうだよなぁ
  • recursive mutex はうんこって話は何度か聞いたことがあった気がして、いくつかあまり意識しないような理由があったよなぁと思ったけど思い出せなかった。意識するような理由としてはここの2つ目の解答とかがあったと思う。 http://stackoverflow.com/questions/187761/recursive-lock-mutex-vs-non-recursive-lock-mutex
    • パフォーマンスとかもあるけどそれは重要じゃない(と言わないと説得力が落ちる)
  • これを途中まで読んだ http://www.boostcon.com/site-media/var/sphene/sphwiki/attachment/2009/05/02/multithread.pdf
  • memcached について id:w_o さんにヨタ話をしたり。使ったこともないくせに
    • 一番大きいのは memcached とかいう話をしている時は、そもそもローカルだけで解決する話をしてない(という脳内設定(ここで現実のサービスの流量は問わない)になっている)ということかなーと思った
    • あとまぁ 1Gbps でもディスクよりネットワークの方が速いという感覚の模様。僕の体感もそうだなぁ。 http://highscalability.com/numbers-everyone-should-know
  • shared_ptr はいずれにせよ一度実装を読むべき
  • mutex 作ったスレッドではロックを全くしないとかいう話はこれなんだけど論文ダウンロードは金かかるみたいだ: http://shinh.skr.jp/m/?date=20080731#p01
  • lock free は無茶苦茶いい話だったと思う。知ってる話も多かったけどここまできちんとまとまってわかりやすく順序だてて聞いたことは間違いなく無い。動画とか上がるならみんな見るべき!
    • 終わってからスライドのコードは while でかこってるんなら weak の方でいいんじゃないですかと聞いたら、次のオブジェクト作るコストによってそれが軽いんなら weak でいいけどそれ場合によるよね、とのこと。なるほどそりゃそうだ
  • Haskell はまぁいつものことだけど使いかたうんぬんよりモチベーションとどう解決したかを明確に知りたいなぁと思った。いつも聞く前より疑問が増える。例:
    • Haskell は並列プログラムの難しいところはだいたい言語で隠蔽できる(笑)
    • $|| とかコードがよくわからんかった。 sieve の方はどこを parallel にしてたんだろうか。
    • parallel だとなんで -feager-blackholing が必要なの、というか普通に考えて「このサンク実行中っす!」フラグは並列だろうとなかろうと必要な気がしてたのでよーわからんかった。
    • 例で出されてた quick sort とかってたぶんタスク的なのを 2N 個作るんだよなーとか思ってそれ普通に正格に評価するより遅いんじゃねーとか想像して聞いたところ、そもそもバグ踏んでるからわからんとかなんとか。 real world haskell とか言うヤツはみんな詐欺師である
    • nested data parallelism ってなにかよくわからず
    • STM で CAS ってなにかよくわからず
    • last core parallel slowdown / spin lock? とかメモった上に質問したけどよくわからず。なんで CPU 一個残すと遅くならないの?
    • 並列プロファイラのモチベーションがわからず
  • id:kazuhooku さんに話を色々聞けてよかった。特にお聞きしたかったのは下記の2点なんだけど、特に銀の矢はここにも無いようだった
    • なんでも一人で上から下までやっちゃうのってすごくないすか→経験。あと IRC で聞く
    • 一人でやってると「おやまの大将」というか、全然ベストじゃない解に落ち着いちゃう不安とか無いすか(実際一人じゃなくても企業ごとに脈々と伝わるベストじゃないけど適度に動くライブラリとかそういうのあると思うんだよな)→あるかも。あと IRC で聞く

(00:27)

_ IEにあわせて

http://tinyurl.com/yc5ptjm

の fugafuga が WebKit と IE で動作そろえてて涙ぐましいとかいう話をしていたら、下の 3 つくらいが一致してないと気付いた。

ちなみに WebKit の該当コード。文字列長を3でわってどうこうとかやってるそうな

http://trac.webkit.org/browser/trunk/WebCore/dom/StyledElement.cpp#L346

(22:56)

本日のツッコミ(全3件) [ツッコミを入れる]
_ 酒井 (2014-05-24 02:45)

当日どういう話だったか知らないけど……

> nested data parallelism ってなにかよくわからず

直列処理を複数のデータに対して並列に適用するのが普通の data parallelism で、並列処理を並列に適用することを許すのが nested data parallelism 。

> parallel だとなんで -feager-blackholing が必要なの、というか普通に考えて「このサンク実行中っす!」フラグは並列だろうとなかろうと必要な気がしてたのでよーわからんかった。

Haskellの大部分である副作用のない計算は、重複実行しても意味的には問題ないので、それらに関しては「このサンク実行中っす!」フラグは必須というわけではないです。
ただ、重複実行を防いだり、他にも幾つか良いことがあるので、並列でも直列でも普通はフラグを使いますが。

で、直列だと単にフラグをサンクに立てれば良いのだけど、並列の場合にはサンクの実行を開始する度に排他処理してフラグを立てていると、(大量にサンクを実行するHaskellでは)性能上問題になるので、重複実行を完全に防ぐことは諦めて適当にやるのが lazy black-holing や eager black-holing 。

> 並列プロファイラのモチベーションがわからず

単にGHCのチューニングのために実行時の振る舞いを見たいというだけだったような。

_ shinh (2014-05-24 02:45)

おおありがとうございます!

> 直列処理を複数のデータに対して並列に適用するのが普通の data parallelism で、並列処理を並列に適用することを許すのが nested data parallelism 。

なるほど大変わかりやすい。配列を4つに切るのが普通ので、配列を2つに切ったやつをさらに2つに切って…みたいなことやったものを並列にどうこうさせるとかそんな感じですかね。このあたりは質問もしたけどわからんかったので今度見かけた時に疑問を覚えていたら質問させてください。

> Haskellの大部分である副作用のない計算は、重複実行しても意味的には問題ないので、それらに関しては「このサンク実行中っす!」フラグは必須というわけではないです。ただ、重複実行を防いだり、他にも幾つか良いことがあるので、並列でも直列でも普通はフラグを使いますが。

僕の脳内にあった Haskell 処理系はそういうフラグが無いと一見問題なく見えるけど実はものすごい数再計算が起きてしまう、ってことが起きそうな気がしてたのですけど、やっぱそういうフラグ使うんですね。納得です。

> で、直列だと単にフラグをサンクに立てれば良いのだけど、並列の場合にはサンクの実行を開始する度に排他処理してフラグを立てていると、(大量にサンクを実行するHaskellでは)性能上問題になるので、重複実行を完全に防ぐことは諦めて適当にやるのが lazy black-holing や eager black-holing 。

なるほど。なんか逆だと聞いたような。単に勘違いしただけの可能性が大なので今度動画でも確認します。

_ 酒井 (2014-05-24 02:45)

> 配列を4つに切るのが普通ので、配列を2つに切ったやつをさらに2つに切って…みたいなことやったものを並列にどうこうさせるとかそんな感じですかね。

そんな感じだと思います。
モチベーションとしては、疎行列とかグラフみたいな一様でないデータ構造を並列処理したいというのがあります。

> なるほど。なんか逆だと聞いたような。単に勘違いしただけの可能性が大なので今度動画でも確認します。

現在のデフォルトの lazy black-holing より eager black-holing の方が重複実行が起こりにくいので、その事を言っていたのではないかと。
(lazy black-holing は、GC時にサンクにフラグを立てて、同じサンクを実行中のやつが複数いたら止めるという感じ。eager black-holing はそれに加えて、サンクの実行開始時に「排他制御せずに」とりあえずフラグを書いておくという感じ。)

お名前:
E-mail:
コメント:
人生、宇宙、すべての答え
本日のリンク元

2010年
2月
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28
1.shinh(2014-05-24 02:45) 2.n(2014-05-24 02:45) 3.naoya_t(2014-05-24 02:45)
search / home / index

全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。

shinichiro.hamaji _at_ gmail.com / shinichiro.h