トップ «前月 最新 翌月» 追記

はじめてのにき

ここの位置付け

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|

ToDo:


2010-07-01

_ jsdo.it

割と面白いかなぁ。 保存しないと反映されないんだけど、 html なんだからもうリアルタイムで更新してくれてもいい気もするな。 JS とかは保存を待って欲しいかもしれんが。

縦書きを transform でやってるのがあったので、 適当に flexbox でもやってみた。

http://jsdo.it/shinh/3dhP

Firefox だとびろーんと長くなった、が気にしない方向で。

(00:37)

_ 楽天

つまり僕の転職候補会社が一つなくなったということだけど、 元々その可能性はとても低そうなので別に関係なかった

いや、しかし、これで楽天が大成功しちゃったりすると、 他の企業もマネしたりして、 つまり僕の転職候補会社が減っていく、 そういうことになると大変悲しいのだけど、 元々その可能性はとても低そうなので別に関係なかった

(23:23)


2010-07-02

_ 歯医者さん

しばらく通院していたのだけど 2週間前にすっぽかして、 そのまますっぽかしたということにすら気付かないまま、 今に至っていると、気付きました

(23:26)

_ RIP CGI

http://d.hatena.ne.jp/nurse/20100702#1278054508

CGI 好きなんだけどなぁ。

Process isolation というのは本当にいいもので、 つまりこう Ruby がクラッシュしようが メモリバカ喰いしようが、 そのプロセスさえ死んでくれればいいわけで、ねえ。

ゴルフ場はなんとなく FastCGI だけど、 正直 CGI の方がいいんちゃうかなーとかたまに思う。 なんかたまにメモリ大量消費してて、 よくわからん。

しかしまぁ、僕とかは ruby で web のなんか作る人間としては、 それこそ CGI.rb にそれなりに我慢ができる程度に 圧倒的にライトユーザなので、 まぁ意見としてはどうでもいい層なんだと思う

(23:56)


2010-07-03

_ lenovo

今度は 17 万以上のマシン買ったら 5 万引かー。 うまいことやれば 30% 引きってことだなぁ。 どんどんエスカレートしていく気がするんだが レノボ大丈夫すか

(00:48)

_ オールインワンPC

っていうジャンルがあるんだなぁ。 よく考えるとメインなノートPCのキーボードとかいらんわけだし、 もうこういうのでいい気がしてきた。

要求としては

  • フルHD
  • なんかグラボ
  • i[3-7]

この条件を満たしてなるべく安いものならいいと思った

(12:30)

_ よくわからんし

暇だか秋葉でも行くかのう…

(12:33)

_ Haskell Quiz

http://blog.hackers-cafe.net/2010/06/haskell-quiz.html

むうむつかしい

(13:58)

_ paged media

dev channel 出てるなーということで入れてみた。

とりあえず linux は paged media 入ってるなぁ。

Win と Mac は間に合ってないっぽいな。 ちゃんとテストせんとなぁ…

(15:22)

_ myrurema

http://route477.net/d/?date=20100702#p01

便利そうなので refe から離れるべく入れてみた。

rurema とか長いよってことで rure にした

(15:40)

_ つか

man と apropos で良くねーと思った。

どうも Perl module と OCaml は man が入ってるみたいだ。 C++ の STL とかはあるわけだし、 Ruby とか Python も man にしておいてもいいんじゃないかな。 あと JavaScript も欲しいな

(15:51)

_ polipo

http://www.pps.jussieu.fr/~jch/software/polipo/

という cache する http proxy があるらしい。

filtering もできるっぽいから、 mod_python_filter とか使うのやめてこっちでいいかなぁ。

(16:13)

本日のツッコミ(全4件) [ツッコミを入れる]

_ Gimite [そういえばSTLのmanってどこにあります?探してみたものの、見つからず…。]

_ yutak [Fedora では libstdc++-docs というパッケージに入ってました 他のディストリでも似たような名前の..]

_ shinh [Debian sid と Ubuntu Hardy では libstdc++6-doc でした。]

_ Gimite [どうもです。Ubuntuでlibstdc++6-4.2-docというのに入ってました。libstdc++6-4.3-..]


2010-07-04

_ $

そうか $ をいじるという手があったかー

http://gist.github.com/462815

僕は fromInteger いじれるといいのかなぁとか思ったけど、 instance Num すると + を再定義せざるを得ないっぽいので どうしたもんかーという程度でとまってしまった

(06:39)

_ :

pm の man はあったものの w3mman で見れなかったので修正

http://github.com/shinh/w3m/commit/b9ad76673b43feba10f4d968948c8e44588f8334

(06:44)

_ キャラジェネ

スプライトみたいなもんだと思ってたけど 正確にどいうもんなのかわかってないなーと思ったのでぐぐった。

グリフだったのか…

(07:00)

_ こわいはなし

http://atnd.org/events/5073

すっかり忘れてた… 今からでもなんか書こう。

バイトしてた時の最初のプロジェクトは 大変社会勉強になるコードだった。

less とかで読んでいると、 どうも 2 行に 1 行空行が入っていて、 ヘンな style だなぁと思ったのだけど、 実は 20 段くらいネストしてるから 空白だけで 80 column 越えしてたのだった。

そのネストした中身はコピペな感じなコードなのだけど、 なかなか内容もためになった。

どういうものかということで一つ覚えているものを。 直線がたくさんあって、 その直線群、つまり

struct Line {
  float start_x, start_y, end_x, end_y;
}
vector<Line> lines;

とかいう lines があったとして、 その lines がループを形成しているかを判定したいらしい。

どうやってやってやるかというと、

  • まず、 lines を構成する全ての頂点の平均を求めて中心を求めます
  • その中心からランダムな直線を 100 本引きます
  • 100 本全ての直線が lines のどれかと交わっているようなら、つまりループになっているでしょう

複雑なコードの管理能力と、問題解決のための独創的な発想の2点で、 そのコードを書いた人は頭いいと思った。 つまりこう、頭は悪い方がいいのだなぁと勉強になった。

(07:22)

本日のツッコミ(全3件) [ツッコミを入れる]

_ ogijun [なんか身におぼえのある話が..]

_ shinh [楽しかったですね。]

_ nishio [「($)を定義していない」って書き忘れた…]


2010-07-05

_ w3m

http://d.hatena.ne.jp/yshl/20100704#1278255925

おおありがたや、ということで適当に

http://github.com/shinh/w3m/commits/master

(00:45)


2010-07-06

_ 1.5倍とか

http://www.kmonos.net/wlog/111.html#_2334100705

なんかこの話は gus さんと何度かしたのでなんか書く。

結論としてはなんか C++ が残念な気がするという話なんだけど、 メモリアロケータの実際とか自信無い面があるので少しあやしい。 全く測定とかはしてないし。

まず、要素数が少ない時。

この時はどうせメモリアロケータ的に 穴もへったくれもなくてサイズごとのプール使ってるんじゃないのか。 そしてキリのいい数字の方がサイズごとのプールにちょっきり入りそうだし、 倍々でいいんじゃないの。

次に要素数多い時。

なんか mmap しはじめるはず。 ということで使い捨てたメモリは munmap されるだろうし やはり依然として穴とか関係ない感がある。

ただやはり瞬間的に要素数 * 3 のメモリが必要になるわけだし、 このへんになると直感的に 1.5 倍とか少なめな方が良さげな気もする。

そもそも要素数が大きくなってくると realloc が mremap になっていって、 mremap ならそもそも アドレスが移動しようがコピーいらなくなるんじゃね? ならし計算量どころか毎回 O(1) なんじゃね? という話を gus さんにした。

すると C++ の allocator は realloc しないと教えてもらった。 kinaba さんが引用している comp.lang.c++ の 議論にもあるけど、 C++ の vector は、 必ず、次の領域の allocate => コピー => free って感じでやる、らしい。

さて、仮に C++ の allocator に realloc があったらいいのかっていうと、 どうも realloc ではうまくいかない気がする。 というのは non-POD な型の場合、 アドレスの移動が起きた場合、 適切にコピーコンストラクタ呼んでやらないといけなくて、 しかし realloc でアドレスが変わった時って、 前の pointer は既に free されているのよね。

なんか話としては

  • is_pod とかを駆使して pod が vector に入ってる時くらいは realloc にする
  • あるいは user がアドレス移動 OK だよ、と vector に policy として伝える
  • デフォルトでは何もしない move_address とかいう関数を全てのクラスに暗黙で定義されるようにしておいて、アドレスの変化が重要な子はそれを定義
  • そもそも realloc がアドレス変える時に古い address が free されてるのが悪くて、 address が変わる時は user が free しなければならない realloc があればいい
  • あるいは、アドレスが変わる時は失敗する realloc があればいい
  • mremap ならそれはできるはずなので、サイズが大きくなった時用の allocator だけは自分で…

などなど。なんか C++ ダメなんじゃないかと思った。 0x とかで解決されてるよ! とかだったらすいません。

(02:22)

_ コピーコンストラクタ

でその議論の結論としては

#include <stdio.h>

struct S {
    S(const S& s) {
    }
};

int main() {
    // copy コンストラクタを定義たせいでデフォルトコンストラクタが無い時は
    //S s;

    // こうすればいいよ!
    S s(s);
}

(02:32)

_ RIP相対

http://twitter.com/kazuho/status/17851784436

x86-64 の場合、無いと大変なことになる系かなと

何故でしょうか!!!

とかいうのはめんどいので書く。

x86-64 さんは、こうアドレス空間が広いです。 64bit 。 x86 と同じ 32bit 絶対でデータを mov とかしようとすると、 届かないことがあったりします。 つまりどういうことかというと、

void foo() {
    puts("foo");
}

をコンパイルして objdump する。

> gcc -c -g rip.c
> objdump -Sr rip.o

rip.o:     file format elf64-x86-64


Disassembly of section .text:

0000000000000000 <foo>:
void foo() {
   0:   55                    push   %rbp
   1:   48 89 e5              mov    %rsp,%rbp
    puts("foo");
   4:   bf 00 00 00 00        mov    $0x0,%edi
        5: R_X86_64_32 .rodata
   9:   e8 00 00 00 00        callq  e <foo+0xe>
        a: R_X86_64_PC32 puts+0xfffffffffffffffc
}
   e:   c9                    leaveq
   f:   c3                    retq

とかすると、まぁ callq の引数部分が 32bit 相対になっていて、 ここがその、 so とかになった時に loader が解決できない可能性があるわけ。

で、それが理由で普通に -shared とかすると、

> gcc -g rip.c -shared -o rip.so
/usr/bin/ld: /tmp/ccbHkebh.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC
/tmp/ccbHkebh.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
zsh: exit 1     gcc -g rip.c -shared -o rip.so

とまぁ怒られるわけです。つまりどこにでも置けるように PIC (position independent code) にしやがれ、と。

で言われた通りに -fPIC とかつけるとどうなるかっつーと、

0000000000000000 <foo>:
void foo() {
   0:   55                    push   %rbp
   1:   48 89 e5              mov    %rsp,%rbp
    puts("foo");
   4:   48 8d 3d 00 00 00 00  lea    0x0(%rip),%rdi        # b <foo+0xb>
        7: R_X86_64_PC32 .rodata+0xfffffffffffffffc
   b:   e8 00 00 00 00        callq  10 <foo+0x10>
        c: R_X86_64_PLT32  puts+0xfffffffffffffffc
}
  10:   c9                    leaveq
  11:   c3                    retq

こうなる。 ここに rip 相対が登場して、 .text と .rodata の相対的な位置は変わらんようにしてある (っていうかまとめて mmap するって話だと思う) のでちゃんと relocation できますめでたしめでたしというような。

ちなみに x86 だとどうなるかというと、

00000000 <foo>:
void foo() {
   0:   55                    push   %ebp
   1:   89 e5                 mov    %esp,%ebp
   3:   53                    push   %ebx
   4:   83 ec 14              sub    $0x14,%esp
   7:   e8 fc ff ff ff        call   8 <foo+0x8>
        8: R_386_PC32 __i686.get_pc_thunk.bx
   c:   81 c3 02 00 00 00     add    $0x2,%ebx
        e: R_386_GOTPC _GLOBAL_OFFSET_TABLE_
    puts("foo");
  12:   8d 83 00 00 00 00     lea    0x0(%ebx),%eax
        14: R_386_GOTOFF .rodata
  18:   89 04 24              mov    %eax,(%esp)
  1b:   e8 fc ff ff ff        call   1c <foo+0x1c>
        1c: R_386_PLT32 puts
}
  20:   83 c4 14              add    $0x14,%esp
  23:   5b                    pop    %ebx
  24:   5d                    pop    %ebp
  25:   c3                    ret

なんか call が増えて大変なことになる。 __i686.get_pc_thunk.bx の定義は

08048416 <__i686.get_pc_thunk.bx>:
 8048416:       8b 1c 24                mov    (%esp),%ebx
 8048419:       c3                      ret

という感じで、まぁ要は call で eip 取ってくるテクニック。

ところで、 なんで call pop じゃダメなのかは知らない。 intel さんが call があると ret やーというような解析を もりっとしていて、 call したのに ret しないと遅くなるとか そいうことだったりとかかなーとか妄想するが知らない。

あと、たしか、 x86-64 は 64bit 絶対 call とか、 64bit 絶対参照とかあったと思う。 このへん使えばどこにでも届くわけだけど、 やらないのは、どうせ PIC の方がいいじゃん (リロケーションのコストとか的に) ってことなのかなぁ。知らない。

(23:33)

_

こいう話は TCC の時に色々 考えたりしたので、 どっかで話したりする機会ないかなぁとか思いつつ今に至ってる気がする。

謎のメモが出てきた。

http://shinh.skr.jp/m/?date=20090331#p06

(23:36)

本日のツッコミ(全7件) [ツッコミを入れる]

Before...

_ kosaki [なんかどこかで聞いたことある話だと思ったらmameさんがズバリ書いていてくれた。なんというエスパー]

_ shinh [おおたしかに再ヒットしてますね面白い。ただ、 linux+glibc だと後半半分くらいの overlap 、つまり..]

_ Rui [CALLとRETをペアにするほうが速いというのはどこかで読んだなーと思ったらAMDの最適化マニュアルでした(*1)。..]

_ m.ukai [> call pop 今時は平気で最適予測できると思いますが、return stack buffer を実装した初..]

_ shinh [Rui さん m.ukai さんコメントありがとうございますです。 ご指摘の通り、 -mtune= で call/..]


2010-07-08

_ らくてん

あの英語は失笑を招くほどひどいらしい。

みんな英語うまくていいなぁとしか思えない。

や、日本ぽい発音てのはそだけど、 どう考えても通じると思われるので別にいいじゃんね…

あれがダメだっていう人はこう、 インド英語とかもダメってことになると思うんだよな。

なんか楽天に関しては色々思うことが混じっていると思う。

  • 英語のクオリティは普通に必要十分じゃね
  • 記者会見英語でやるのは意味ない感強いけど、まぁパフォーマンスみたいなもんなら別にいいんじゃないかな。今後もずっと続くとかならよく知らんけど
  • 国際競争力つけようと努力すること自体は一般的に言うといいことなんじゃないかね
  • 普段「日本から世界に通用するサービスが出てないのは何故か!」とか論じてる人は素直に応援してあげたらいいんじゃ
  • ところで英語自体はこわいので自分の会社とかであんなことが起きたら悲しいと思う
  • 特に多少なりとも愛社精神があったりすると悲しいと思う

最後の意味でこいう意見はとてもこわい。

http://d.hatena.ne.jp/nishiohirokazu/20100707/1278509600

僕個人はさっさと転職を選択すると思うけど、 しかし仮にうっかり愛社精神が強くあったりしたら悩むと思うので、 英語ができないくらいで仕事できないとか言われることになって、こわい。

ところで、よく TeX とか C とか人を長期に渡って 苦しめててひどいとか言うけど、 英語の方がよっぽどひどい言語と

(00:59)

_ C の代替

なんか C はいいものだけど、 ハードウェアってそれなりに変わったらしいし、 C の守備範囲でもちょいなんか無いもんかねみたいな話を よくしたり聞いたりするんだけど、 なんか機能で考えるより何が実装できればいいかを考えればいいんかな。

アセンブラや言語拡張無しで、

  • バックトレース書ける
  • JIT 書ける
  • closure 書ける
  • GC 書ける
  • 高速な画像/動画処理できる

このあたりかなぁ。

(02:05)

本日のツッコミ(全5件) [ツッコミを入れる]

_ ささだ [backtrace? stack frame に対する操作ですかね.一瞬バックトラックかと思った.大体同意します...]

_ shinh [x86-64 は stack frame 無いので言語なりライブラリがそいう抽象化レイヤーを提供してくれないとどうに..]

_ n [時間をかけた完璧なsimd化と、そのキャッシュがあれば十分な気がします>ベクトル命令 最適なメモリアラインがCPUア..]

_ shinh [SIMD って完璧にできるんですか? なんか画像処理とか暗号とかの最内ループ付近は結局アセンブリ手書き的な感じなのか..]

_ shinh [あ、あともちろん「ほとんどのケースでは C で十分である」的なことはその通りだと思います。ただ現状の C は高級アセ..]


2010-07-09

_ アルファベット only perl

http://shinh.skr.jp/dat_dir/mederu/041.html

ここで「たぶんできそうげ」と書いた、 アルファベットだけの Perl で任意コード実行だけど、 今考えると比較的簡単にできるのであった。

同じく quine も書けると思う

今度なんか書く

(02:35)


2010-07-13

_ 散歩

なんで駒場に行かにゃならんの… ということで雨もふるし大変うざい選挙になってしまった。 どうも期日前投票するべきだったみたいだ。

好きでない共産党にわざわざ投票しに行ったのに 落選してしまったのでかなしかった。 タリーズめ…

しょうがないのでついでになんかしようとマンガを 読んだり買ったり。

読んだ:

ドリフターズは普通に面白そうだなーと思った。 ローマとカルタゴの人を知らんかったのでちょっと歴史の勉強した。

眠れる惑星。 あいかわらずストレートに都合のいいエロマンガかく人だなぁとか思った。

打撃天使ルリ。 3巻で終わってたのかー。 1巻あったら買ったんだけどな。

殺しや1の人とのぞき屋は同じ作者だったようだった。

罪と罰はなんか時代ずらしただけじゃなくて、 ソーニャの立ち位置とか全然違うっぽい。 なんかラスコーリニコフ役から信念が感じられないのがいけてないなぁとおもった

カイジ。つまり福本先生この話実体験ってことすか…的な

あと忘れたけどもろもろ。 燃えよペンってもっとぶっとんでた気がしたんだけど、 今見るとなんかそうでもない気がしてしまった。

買った:

地雷震1。最初の方はどうしようもなく救われなくていいよね。 そういえばウシジマ君もなんか少しいい人になってて そのへん地雷震ぽい気がちょっとした。

ジャぱん18 はですよがついてる話を読んでおこうかなぁとか思って買った

初期のURASAWA 。激しく読んだことあった。

劇画自民党総裁。勉強になった。

まるごと西原理恵子。 西原理恵子のマンガの読み方としては これはすごくいい売り方な気がするなぁ。

恐怖新聞。 うしろの百太郎の方が事実として押しつけてくる感が強い感じなのかな。

そんなことよりやりたかったことはあるはずなんだけど無駄な日曜になった

(23:53)


2010-07-18

_ niconico

http://twitter.com/lyrical_logical/status/18776878242

芸風的に雌豚先生復活とかだと嬉しいなー。 動画丁寧すぎるのがそれっぽくないけど。

(10:09)

_ wake

C++ で書いたらだいぶ速くなった。 20-30倍くらいか。

基本正規表現だけだからこんなに速くなると思ってなかったんだけど、 まぁ Ruby の方のコードは色々適当なのが悪いんじゃないかと思う。

all: "$(loop0)"

loop3000000: "DONE\n"
loop(\d+): loop$(add($1,100))

#include "std/num.wake"

とかが 2 秒とかかかってて、 ちょっとまだ遅すぎるよなーという感がある。 16kHz とかくらいか。

ターゲットが増えると遅くなるってのはいけてないので、 なんかそのへんなんとかなるといい。

二つほど方法はあって

  • 正規表現を合成する
  • 各正規表現の先頭部分に関して trie を作る

とかかなぁ。

正規表現の合成って特に後方参照的な意味で 難しそうな気がするけどどうなんだろうな。 普通に \1 とかの番号を振りなおすだけでいいのかな。 とりあえず \10 とかは使えるんだなーと確認した。

うーんでも trie かな

(13:59)

_

うざい遊びをしててすいません

単にこのエロ動画の話 http://www.nicovideo.jp/watch/sm11381844

(14:18)

_ memset

http://twitter.com/hamano/status/18818137867

https://review.source.android.com/#patch,sidebyside,14699,1,libc/memset.c

ありそうすぎて笑った。

/bin/grep -r --include='*.cc' --include='*.h' --include='*.cpp' --include='*.c' memset *

とかしてみたところ、

SDL_command/SDL_command.c:    memset(cmd->input_queue, -1, sizeof(int)*input_queue_size);
marathon/SequenceAlignment/sa2.cc:    memset (F, -1, sizeof (F));

ごく稀にはあることがわかった。

(14:32)

_ dc.sed

簡単だと思っていた引き算が意外とめどい

dc.sed は何故 add と sub を同時にできてるんだ…

: addsub1
	s/\(.\{0,1\}\)\(~[^,]*\)\([0-9]\)\(\.*\),\([^;]*\)\(;\([^;]*\(\3[^;]*\)\).*X*\1\(.*\)\)/\2,\4\5\9\8\7\6/
	s/,\([^~]*~\).\{10\}\(.\)[^;]\{0,9\}\([^;]\{0,1\}\)[^;]*/,\2\1\3/
#	  could be done in one s/// if we could have >9 back-refs...
/^~.*~;/!b addsub1

ええ理解不能です

(15:43)

_ ああそうか

引き方を先にマッチさせればいいのか。 やはり簡単だった…

(15:45)

_ ぼとるねっく

perftools でプロファイル取ってみたところ、 正規表現とかでは全然なくて、 malloc 多すぎとかだった。 とりあえず string::reserve 呼ぶとだいぶ速くなった。

あと tcmalloc 使うとだいぶ速くなる。

ベンチマークは大事だなぁと思った。

で、前回の話から考えると、 std::string じゃなくて自分で string 作った方が速くなるんないか…

(18:02)

_ perftools

libpcre の symbol 取れねーなーと悩んでいた。 profile の末尾についてる /lib/libpcre... とかを /usr/lib/debug 以下のものに置換すればとりあえず取れるみたいだ。

inline 展開のせいでよくわからんのだけど、 たぶん、

  • 少なくとも 31.8% は pcre_compile
  • 20% くらいが pcre_get_substring_list ?

って感じっぽい気がする。 とりあえず後者は簡単に減らせるはずだ。 pcre_exec の返す ovector のフォーマットが わかるといいんだけどな。

      The  first  two-thirds of the vector is used to pass back captured sub-
      strings, each substring using a pair of integers. The  remaining  third
      of  the  vector is used as workspace by pcre_exec() while matching cap-
      turing subpatterns, and is not available for passing back  information.
      The  number passed in ovecsize should always be a multiple of three. If
      it is not, it is rounded down.

3倍ってなんだと思ってたんだけど、そういうことか…

(20:09)

_ pcre_get_substring_list を取り除いた

全然速くならない。 普通に pcre_exec が遅かったみたいだった。

RE2 はどうかなーと思ったんだけど、 backreference が無いみたいなので論外だった…

Irregexp とか YARR とか使ってみるという手もあるんかな。

ぱっと見では YARR の方が切り出しやすそうな雰囲気かなぁ… と思ったけど wtf とかに依存してやがるな。

Irregexp にするか… とか思ったあたりで何やってるんだろうと思いはじめてきた。

(20:59)

本日のツッコミ(全2件) [ツッコミを入れる]

_ naruse [正規表現ライブラリ、TREってのもありますね。http://laurikari.net/tre/]

_ shinh [おお、ぱっと見良さそうですね。速ければ、ですが。ありがとうございます。]


2010-07-19

_ swap

http://d.hatena.ne.jp/nishiohirokazu/20100622/1277208908

http://d.hatena.ne.jp/nuc/20100716/p17

via http://twitter.com/gusmachine/status/18840198768

@gusmachine さんいいこと言うなあ…ってのはいいとして。

id:nuc さんは空間使用量が O(N**2) で増えていく、 と書いてあるけど、そうなん? と思ってしまった。 fibonacci の多倍長整数のオーダーが O(N) になるのか。

で…

fib_time.gif

2.77618e-13*x^2.55 の方が 2.10854e-10*x^2 よりどう見てもマッチしてるな。 特異的って感じもないと思う。

まぁ Haskell とか不思議の塊なので、深く考えるのはやめ。

で、メモリ。

fib_rss.gif

うーん O(N)。

まぁ Haskell とか不思議の塊なので、深く考えるのはやめ…

(02:10)

_ ちなみに

二つ目のグラフの a == 0.668326 だそうです。 そしてメモリの縦軸は kB 。 つまりメモリ使用量が 668 Bytes ずつ増えていく計算になるわけですが…謎。

もう少し上まで

fib_time2.gif

a               = 3.16989e-10      +/- 1.038e-11    (3.274%)
b               = 2.63344          +/- 0.007344     (0.2789%)
c               = 1.01622e-13      +/- 9.684e-15    (9.53%)

fib_rss2.gif

a               = 0.642804         +/- 0.007101     (1.105%)

ソースコード

http://github.com/shinh/test/commit/79d93f47d025f841ee9a7639bf3b493d918b86b0

(02:27)

_ wake

名前は

  • kati はやっちゃったから hikiwake かなぁ
  • てか wake って m ひっくりかえした make っぽいね
  • 作りはじめた時に眠かったのに作りたくなって無理矢理起きて作ってた

のでちょうどいいと思った

あと一日中雌豚先生の作業用 BGM 聞いてた結果、 たしかに違うかなーと思った。

(02:42)

_ bf.bef

書いた記憶があるのにどこにもないなぁと探しまわった。

見つかった…

http://d.hatena.ne.jp/shinichiro_h/20100121#1264012341

検索用: befunge brainfuck bfint.bef brainfuck.bef

(02:51)

_ WebKit

たいしたことじゃないけど

http://ss-o.net/webkit/extension/browser.html#Page5

個人的な感覚ではあの switch case は必要悪かなぁ。 分離されてるとかえって不便な気がする。

グローバル変数も過去の遺産っていうか省メモリやら キャッシュしたいやらでしょうがない面も強い、かな。 ただ省メモリ用のハッシュとキャッシュ用の static 変数でのハッシュは、 それぞれ class 作って抽象化しておけば、 いざ thread safe にしたいとか思った時にやりやすかったかもー という意味ではまぁ過去の遺産と言われてもしゃーないか。

http://ss-o.net/webkit/extension/browser.html#Page10

WebKit2 の説明はちょっと意味がわからなかった。 どっちの説明も「なので、」までは正しいと思うんだけど、 後半はどっちもそうなんじゃないか。 WebKit2 もたぶんタスクマネージャ見たら たくさん起動してるだろうし、 どっちも1つのアプリケーションの中でプロセスを分割してるし…?

Chrome は ... なので、使いまわせない。 WebKit2 は ... なので、使いまわせる。 とかがこの文脈で言える唯一のことじゃないかなぁ。

出てきたころは、 WebKit2 はまだ新しいので、 セキュリティうんぬんとか詳しいこと考えてるのかなーとかいうのは 言えたっぽいんだけど、 まぁ今はさっぱり動きとか見てないのでわからない。

(12:56)

_ SSE 命令

http://msirocoder.blog35.fc2.com/blog-entry-58.html

これは大変便利げな

(13:06)

_ wake の page

As of September 18, 2010 とか書いてあった。 未来に生きてるなー。

正解は July でした。

さっき昨日ビルドしたはずのファイルに ls -l して、 July とかでてきて、 えーと July って 5 月じゃないかにゃー ヘンだにゃーと思ったところで、 そもそも July は今月だと気付いた。

英語の月名は難しいよなあ…

(13:19)

_ ものはついでと申します

ruby1.9 (git-svn-id: http://svn.ruby-lang.org/repos/ruby/trunk@28675)

fib_time_rb.gif

a               = 1.02084e-10      +/- 2.187e-12    (2.143%)
b               = 2.47454          +/- 0.0404       (1.633%)
c               = 3.26532e-13      +/- 1.625e-13    (49.76%)

fib_rss_rb.gif

a               = 0.642804         +/- 0.007101     (1.105%)

コード

n = ARGV[0].to_i
fib = [1,1]
n.times{|i|
  fib << fib[i+1] + fib[i]
}

時間は O(N**2.47454) 。

なにか正直言って、 memory allocator がこんだけ order をいじるんだなぁということを知らなかった。

あと、 Haskell が線型のメモリしか使わないのは、 よく考えたら僕の脳内 Haskell はそいう動きしそうに思ったので、 さして不思議じゃないかなぁと。

java version "1.6.0_18"

fib_time_java.gif

a               = 1.81687e-10      +/- 3.693e-12    (2.033%)
b               = 2.16295          +/- 0.1003       (4.636%)
c               = 2.73763e-11      +/- 3.232e-11    (118.1%)

fib_rss_java.gif

a               = 0.000237798      +/- 5.535e-06    (2.328%)

時間は O(N**2.16295) とのことで、 オーダーのオーバヘッドは少ない。 ただそもそもなんか遅いんだけどな…

import java.math.BigInteger;
import java.util.ArrayList;

public class fib {
    public static void main(String[] args) {
        ArrayList<BigInteger> l = new ArrayList<BigInteger>();
        l.add(BigInteger.ONE);
        l.add(BigInteger.ONE);
        int e = new Integer(args[0]).intValue();
        for (int i = 0; i < e; i++) {
            l.add(l.get(i).add(l.get(i+1)));
        }
    }
}

Java 書いたの超ひさしぶりだー

(13:57)

_ C++

完璧言語 C++ ではどうか。

fib_time_cc.gif

a               = 5.4409e-11       +/- 1.265e-12    (2.325%)
b               = 1.84416          +/- 0.09885      (5.36%)
c               = 3.58202e-10      +/- 4.327e-10    (120.8%)

O(N**1.84416)! O(N**2) のアルゴリズムのオーダーを減らしてくれる memory allocator! すごいです!!

fib_rss_cc.gif

a               = 0.000188953      +/- 7.58e-06     (4.011%)

まぁ途中で memory allocator は サイズの大きい小さいで挙動を変えてるだろうし、 gmp もそいうのあるかもしれないし、 まぁ N**a とかでの fit はあまり意味ないんだろうと思う。

ソースコード。 gmpxx ってえらいですね。 GNU とは思えない。知らんかった。

#include <stdio.h>
#include <stdlib.h>

#include <iostream>
#include <vector>

#include <gmp.h>
#include <gmpxx.h>

using namespace std;

int main(int argc, char* argv[]) {
    vector<mpz_class> v;
    v.push_back(1);
    v.push_back(1);
    int e = atoi(argv[1]);
    for (int i = 0; i < e; i++) {
        v.push_back(v[i] + v[i+1]);
    }
    //cout << v[e] << endl;
}

これまでのあらすじ:

fib_time_all.gif

fib_rss_all.gif

Ruby すごくね

(14:57)

_ あとそうだ

これは GC のある言語に大変厳しいベンチマークなので、 公平性には欠けまくりだと思う。

なんでかっていうとメモリ使用量が増えるばっかりで、 全然 collection されないから。

聞いた話によると、コンパイラとかはこいう挙動をする、 GC 泣かせなアプリの一つらしい。 つまりソースコードを読んでがーとデータ構造作るんだけど、 作るばっかであんま解放する物は無い、というような。

(15:01)

_

適当に D も足しておいた。

時間は O(N**2.5833) ですって。

(16:21)

本日のツッコミ(全3件) [ツッコミを入れる]

_ 白のカピバラ [詳しい実験どうもありがとうございます。 はてなid:nuc です。不思議の塊に足を突っ込んで反省しております。 ちょ..]

_ シンX [配列不要の動的計画法を使えばいいだけの話のような……(とか言っちゃダメなのかな?) ;-)]

_ shinh [もちろんそうなんですけど、いやしかし Haskell のヤツは O(N) の配列は作って無いので、えーとうーん、そっ..]


2010-07-21

_ GC

なんか gus さんの最初の直感、

http://twitter.com/gusmachine/status/18877553931

は Ruby と Haskell に関しては 正しいんじゃないかなぁとか思えてきたんだ…

まず世代を忘れる。 仮に領域を確保するたびに GC が走るアホ GC があったとして、 今回のプログラムはメモリの解放は起きないので、 copying だろうと mark and sweep だろうが 一回の GC の走査量はたかだか N^2 。 それが N 回起きるので O(N^3) になって、 これが最悪のオーダーで、 O(N^2) の領域使ってるんだから O(N^2) 以上はかかるでしょ、 という理由で最小 O(N^2) なので、 まぁ O(N^2) から O(N^3) のどこかにおさまるべきでしょう。

ところで今回のプログラムは、 確かにメモリは N^2 使うんだけど、 オブジェクトの数はたかだか 2N 個しか無い。 だから一回の mark and sweep GC の 走査量は O(N) なんじゃないだろうか。 だとすると仮に毎度 GC 走るアホ GC だとしても、 たかだか O(N^2) じゃね?

…というような理由で、 Ruby の O(N^2.47) が謎に思えてきた。

次に Haskell 。 Haskell はそもそも普通に GC しててメモリ消費量は O(N) なので、 何がどうなってようがたかだか O(N^2) なんじゃなかろーか。

最後に D は、これも mark and sweep なんだろうけど、 コンサバなもんですから、 O(N^2) の空間なめちゃうんじゃないか (Ruby は BigNum の中はなめないよね?)。 つまり、仮にアロケーションのたびに GC が走ってたなら O(N^3) になりうる。

あとはどのくらいの頻度で GC が起きるかってのが問題。 単純に vector みたいに倍々で増やしてたりすれば O(N^2) になるはず。 D の gcx.d とかをチラ見するに、

  • 4k 以上の allocation (たぶん今回はほぼこれだろう) は bigAlloc を通りそう
  • bigAlloc は既存の pool を巡回して、空いてるのが無ければ full GC => それで足りなければ newPool
  • つーわけで newPool 時に allocation するサイズが問題である
  • newPool をざっくり読む
    • まず確保する page 数を今欲しい数の 1.5 倍にする
    • で、 pool の数が 2 個目だと最低でも 2MB 、 次は 3MB …となって、 8 個を越えると固定で 16MB, 32 個を越えると 32MB って感じで pool 最小値を決めていく
    • 32 個を越える段階では 400MB とか allocate してることになる気がするので、結局数 MB から 16MB 程度の allocation をしていく、ってことになるんじゃないかと思う

で、定数ずつ allocation していくとか、 2,3,4,... という感じで定数ずつ allocation する量が増えていく、ってやり方だとあっさり O(N^3) になるわけだけど、数 MB 単位で allocation してるなら、そもそも今回のベンチマーク程度だと、 GC が起きる総数がそんなに多くないので、 O(N^2) の方が十分に強くて、間くらいのオーダーに見えた、ってのはアリかなー。

適当に simulation を書いてみた。

#!/usr/bin/env ruby

use_size = 0
heap_size = 1000000
next_gap = 1000000
num_gcs = 0

simulated_time = 0
gc_time = 0
calc_time = 0

1.upto(100000) do |n|
  use_size += n / 20
  if use_size > heap_size
    while use_size >= heap_size
      heap_size += next_gap

      #next_gap = heap_size
      #next_gap = Math.sqrt(heap_size).to_i
      #next_gap += Math.sqrt(next_gap).to_i
      #next_gap += 100
      if next_gap <= 8000000
        next_gap += 1000000
      else
        next_gap = 16000000
      end
    end

    # Time for GC.
    num_gcs += 1
    gc_time += use_size
    simulated_time += use_size
  end

  calc_time += n / 2.5
  simulated_time += n / 2.5

  puts "#{n} #{simulated_time}" if n % 100 == 0
end

STDERR.puts heap_size / 1024 / 1024
STDERR.puts num_gcs
STDERR.puts gc_time
STDERR.puts calc_time

calc_time を増やす時にかかっている /2.5 は、 gc_time と calc_time をだいたい同じにする程度に normalize している。

これを fit すると O(N^2.55216) とのこと。 この指数は / 2.5 の部分を適当に調整すると色々変わる。

グラフはこんな感じ

gc_sim.gif

つーわけで、 D に関しては実は O(N^3) なんだけど、 GC が適当に現実的なメモリに対してでかいと 考えられる単位で allocation しているので、 GC 頻度が少なく、 O(N^3) の係数が十分に少ないために O(N^2.5833) とかに見えた、って説はどうだろう。

実際数えてみた。 gdb で fib を走らせて、 _D2gc3gcx3Gcx16fullcollectshellMFZk に break 仕込んで cont 連打。N==100000 で 39 回とのこと。 上の simulation コードは 22 回だと言ってるのでそれなりに回数にずれがあるけど、 いずれにせよこんだけ少ない回数しか O(N^2) の operation が起きてないんなら O(N^3) に見えなくても納得できる感じかな。

あと上のコードの next_gap を色々調整してるうちに 気付いたんだけど、 next_gap += Math.sqrt(next_gap) 的な 増やしかたをしていると、 なんか O(N^2.6) あたりになる。 でもまぁそいう実装になってないっぽいのであんま関係なさげ。

(00:35)

_ 39 回の fullcollect

以下は、左から、 GC の回数、その GC の時 fib のどこを計算してたか、前回との差分、って感じ

1 3686 3686
2 5775 2089
3 7165 1390
4 10228 3063
5 13058 2830
6 15618 2560
7 18690 3072
8 22274 3584
9 24939 2665  // ここから毎回 bigAlloc によって fullcollect が呼ばれるようになった
10 29035 4096
11 33131 4096
12 37227 4096
13 41323 4096
14 45419 4096
15 48265 2846
16 50313 2048
17 52361 2048
18 54409 2048
19 56457 2048
20 58023 1566
21 59958 1935
22 62091 2133
23 64139 2048
24 66187 2048
25 68235 2048
26 70283 2048
27 72331 2048
28 74379 2048
29 76427 2048
30 78475 2048
31 80523 2048
32 82571 2048
33 84619 2048
34 88715 4096
35 92811 4096
36 96009 3198
37 98739 2730
38 99999 1260

最初の 1 回はプログラム開始時みたいなタイミングで呼ばれてたので除外。

うーんやたら定期的に呼ばれすぎ感が。 なんかおかしいなぁ。

(01:07)

_ あと

Ruby とか Haskell とかは実は GC とかまるで関係なくて 多倍長整数の実装のしかたとかそのへんが関係してるとか無いもんか

(01:08)

_ shortest

http://blog.hackers-cafe.net/2010/07/shortest-oneline-brainfck-interpreter.html

いくら one liner でも 558B で shortest はたぶん無いなー。

python one liner ってのは面白いネタだと思うんだけど、 ただ exec は封印しないと全く意味ない縛りになっちゃうよなぁ。

とりあえず codegolf.com の top は 200 切ってるし、 僕が適当に書いても 335B とかで書けて、 exec 使って one liner にしたら 362B 。 さてこれをファイルから読むとかやっても 400B にはならんだろーから、 まぁ少なくとも exec 使うのは自粛すべきだな。

で、最短の bf インタプリタって常識的に考えて… っていう意味で矛盾がまたあるんだが。

(01:28)

_ そっちはどでもよくて

http://blog.hackers-cafe.net/2010/07/haskell-quiz-answer.html

こっちは大変勉強になったのだった。 なるほど a とか b の overload ってのができるんだなあ

(01:31)

本日のツッコミ(全1件) [ツッコミを入れる]

_ k.inaba [Haskellのは、自分のとこではO(N^2.6)とか全然再現せず普通にO(N^2)に見えるのでという理由と、とりあ..]


2010-07-22

_ shortest 続き

http://shinh.skr.jp/m/?date=20100721#p04

自分でやらずに shortest は無いなーとか言うのもずるい気がしたので書いてみた。 前に書いた通り exec すると意味なくなるから exec 封印で。 適当に書いて 490B 。別にゴルフはしてない…

import sys;s=[];reduce(lambda a,_:(a[0]or sys.exit(0))and[1>a[3]and a[0][0]==']'and s.pop()or a[0][1:],a[1]+[(a[0][0]=='>')-(a[0][0]=='<'),0][a[3]>0],a[2][:a[1]]+[1>a[3]and a[0][0]==','and ord(sys.stdin.read(1)or'\0')or a[2][a[1]]+(1>a[3]and a[0][0]=='+')-(1>a[3]and a[0][0]=='-')]+a[2][a[1]+1:],a[3]+(a[0][0]=='['and(0==a[2][a[1]]or 1==s.append(a[0])))-(a[3]and a[0][0]==']'),1>a[3]and a[0][0]=='.'and sys.stdout.write(chr(a[2][a[1]]))],iter(set,0),[file(sys.argv[1]).read(),30,[0]*200,0])

(01:03)

_ n 回 7

http://d.hatena.ne.jp/nishiohirokazu/20100721/1279687613

つまり kinaba さんの説通りっぽい感じだなぁ。

まとめておくか

  • Haskell: スタックが O(N) だったことと、 N に比例して allocation する量が増えてくようなパターンだったので GC 頻度が O(N) より大きくなった
  • Ruby: リストが O(N) だったこと、 理由の後半は Haskell と同じ
  • D: なめる空間が O(N^2) で GC 頻度は O(N)

あたりでみんな O(N^2) 以上の計算量になってたって感じか。

D に関しては O(N^3) なんだけど、 GC の頻度少ないので、 O(N^3) の係数が大変小さくて 間くらいのオーダに見えた、と。

正直色々やりたいことある時期に 比較的どうでもいい議論に時間を使いすぎた感もあるけど、 しかし GC は結構むつかしいもんだなーという勉強になった。

そういえば Haskell は stack が O(N) になっちゃうのは避けられないんだろうか。 うーん僕の脳内 Haskell 処理系では無理げだな。 つーことは、無限リストの 1億要素目をいきなり取り出すとか だいたい無理みたいなことになるのかあ。

(04:06)

本日のツッコミ(全15件) [ツッコミを入れる]

Before...

_ shinh [ああなるほど。そういう意味であれば、 Haskell のコードは普通に動的計画法で書いた時のコードに近いものになって..]

_ シンX [ああ、仰せのとおりです orz 多倍長加算のコストを途中で忘れてました。その計算量で良いです。 ところで、計算量理..]

_ shinh [ちなみにサイズ N のスタックになってるのは、 遅延評価された N 番目の fib を取ろうとする => あっまだ..]

_ shinh [でまぁプログラマは遅延する必要無いのはよく知ってるのでこれ正格評価してくだっせーと教えてやれば stack 使わんよ..]

_ シンX [理解しました。解説ありがとうございました。というかわざわざすみません m(..)m]


2010-07-24

_ \n

all: \n \n\n\n
: "FAIL\n"
.: "OK\n"
..: "FAIL\n"
...: "OK\n"

あれなんかこれはおかしい気がするぞ…

irb(main):004:0> /\A\Z/m =~ "\n\n"
=> nil
irb(main):005:0> /\A.\Z/m =~ "\n\n"
=> 0
irb(main):006:0> /\A..\Z/m =~ "\n\n"
=> 0

えーそうなのか。 PCRE 不思議。 改行一個までは無いもんとして扱える、って感じ?

まぁ PCRE がそうなる以上仕様だろうな

(06:41)

_ bot

http://build.webkit.org/results/Windows%20Release%20(Tests)/r63992%20(1883)/fast/text/

なんでまだコケてるんだよボケ! と思ったら r63992 とかで全然追いついてないのか…

この win bot がぶっこわれてる状態がずっと続いてるってのは Apple の人とか困ってないのかな…

もう体感で 2,3 ヶ月くらい壊れてる気がするが 実際どのくらいだろうな。

(07:15)

本日のツッコミ(全2件) [ツッコミを入れる]

_ Gimite [Rubyだと http://doc.okkez.net/192/view/spec/regexp \Z: 文字列末尾..]

_ shinh [おおそう書いてありますねえ。ありがとうございます。たぶん \z を使うべきだったんでしょうけど、まぁ忘れることにしま..]


2010-07-26

_ Akinator

http://jp.akinator.com/

日本語化されたとのことで遊んでみた。

一度外したけど、エミリオミハイロフを当てられて心底びっくりした。 軍人かどうかはむつかしいなーと思った。

JB-5th は当てられなかった。 まぁ結局誰も入力したこと無さげだ

(23:08)


2010-07-27

_ まっくぶっくのトラックパッドのボタン

なんかボタンが押しっぱなし状態になっていたり、 全然押せない状態になったり、 とにかくどっちかに固定されてしまう。 「macbook トラックパッド」で「故障」が suggest されるあたり、 よくあることなのかもしれない。

http://haru3.cool.coocan.jp/archives/pc/mac/08-187-0057.php

になんかなおしかたが書いてあるのでやってみよう…

(22:30)

_ まっくぶっくのバッテリ

トラックパッドのボタンが押しっぱなしになる問題は、 バッテリが膨らんでいるせいだと判明した。

つまり後ろから全力でバッテリが押してやがるから、 ボタンがおしっぱなしになる、と。 なるほどねえ。

バッテリがこの位置になかったら使えてたってことだよなーということと、 しかしこの位置になかったら気付かんくて危険だよなーということと、 を思った。

でまぁこの膨らんだバッテリは、 十分膨らんでいるために、もう中に入らないのであった。 つまりもうまっくちゃん動かないってことなの… と思ったけど、よく考えればバッテリはずせば動くのであった。

ただまっくの電源ケーブルって異様にアッサリ抜けやがるで有名なので、 ケーブル抜けるだけで電源断ってのはキツいか。 まぁいずれにせよ apple store に持って行ってみよう

(23:11)

本日のツッコミ(全3件) [ツッコミを入れる]

_ ogijun [ほっといたら燃えそうなのではやく交換に行ってください..。 はっきり膨らんでるときはたぶんお金かかりません。]

_ shinh [Apple Store に行ったら金取ると言われたのでバッテリは捨てて使うことにしました。あと燃やそうにもふくらみす..]

_ shinh [ていうか同じ症状の人多すぎと思いました。]


2010-07-29

_ くーらー

も壊れたっぽい。

みんな夏ばてかのう

風は出るんだけど冷たくない。 死ぬかと思ったけど窓開けて扇風機まわしたら 普通に寝つけた。 まぁ消してから寝てもタイマーで切れても大丈夫なんだし死なないか…

(06:57)

_ PLT とか

http://shinh.skr.jp/m/?date=20090727#p01

あれから1年たってる!

今一つ覚えてないけど、 なんとなく思い出せるから久しぶりにいじってみるか…

メモを見るに PLT の方が課題って感じ?

(07:32)

_ Mach-O

どうも俺は Mach-O について微妙に知ってるのに、 全然作ったツールとか出てこなくておかしい。 結局見つけたのはこれくらいか

http://spreadsheets.google.com/pub?key=pcoKcHzxsAsgfZ3aSIeDdcQ

(08:31)


2010-07-30

_ shibuya.js

全体的に面白そうだったから行きたかったな。

  • 先日のおかげで赤青眼鏡は手元にあった
  • 顔文字 86 は大変そう
  • JS の timezone はめんどくさいよねえ
  • class2js すごいとこまで行ってるなー

(22:24)

_ LL

shibuya.js が面白かったので LL Tiger 行こうかという気が起きてきた。 やりたいこともあるけど、ノート PC でそれなりに内職もできるだろうしな。

(22:37)


2010-07-31

_ LL Tiger

クーラーこわれてる部屋は暑すぎるので とにかく家にはいられないということで 割とさっくり行く決意ができた。

Perl6 の lazy list の例はどうでもいい感じだったんだけど、 こうフィボナッチ持ってる lazy list とかもできるんだろうな… とこれは後で調べる。 ていうかゴルフ場の rakudo も update するか。 あとゴルフ場の rakudo は1秒ちょいで返事かえすので、 LL Eval はちょっとなんなんだろと思った。

LT は例のごとくお前らボケてる暇あったら技術の話しろ… っていうのも多かったなぁ。 記号 x86 とか無説明すぎて結局意味なかった。 まぁあれは当人じゃないからしょうがなかったのかも。

ライセンスと電子出版とフィジカルコンピューティングはそれぞれ 面白かったと思う。それぞれあんま LL ぽくないけど。

JSC/v8 の worker が native thread か否かとか、 まぁ普通に知らん。 まぁスレッド間通信が message passing しか無い以上、 native thread かつ giant lock も無いだろうなぁという 予想は高確率で当たってると思う。 ruby とか python は処理系作ってる人が愚かなのではなくて、 単にメモリ共有する thread だからしょうがなく giant lock …って話だと思う。 いずれにせよ僕は reviewer であるという言い訳ができるので あの場にいた唯一の committer であろう omo さんの罪は重い。

さて message passing というのは、 mootoh さんに完全同意で、並列屋には極めて重要な primitive になるんだろうなーと思う。 message passing って何な質問に MPI を例にしたのはたぶんあまりいい解答じゃなくて、 さっと答えるのは結構大変なんじゃないかなーと思う。

重要なところは、

  • 共有メモリによって、こっそり行なわれてる通信を排除もしくは強く制限する
  • で、通信は明示的に message passing でやりとり

何が嬉しいかというと

  • 最悪のバグの一つであるところの、 race condition が無い
    • これは半分嘘で、同じメモリに同時に触っちゃったー的な race condition が無いだけで、アプリケーションロジックにバグ入れるとかはいくらでもできる
    • が、それもまぁそれなりに message passing 前提な API をうまいこと切ればだいぶ抑制できるんじゃないかね
  • データ待つ系の処理は lock いらない
    • これはメリットなんだろうか

あと僕の強い希望として

  • 言語作る人は message 送ってきた元の stacktrace を送られた側から参照できるようにしておいてください…

でまぁ、これまたオブジェクト指向並に 「短くて必要性を強く訴えられる例」を 考えつきにくい機能なんじゃないかなぁとか漠然と思った。

オブジェクト指向で猫と犬がニャーワンって、 結構あれがわからんという人は 身近にもネットにも結構いたと思う。 僕はオブジェクト指向ってのは それなりにすぐにわかったんだけど、 まぁ僕が天才であるとかではなくて、 単純にそれまでに書いたコード量の問題だと思う。 message passing とかも それまでに thread のコード書いて、 race ったり race ったり race ったり してるとまぁ感覚的に必要な気がするんだよね。

でもまぁうまい例を考えてみるのはいいと思う。

それにしても暑すぎるので明日もどこかに行かんといけない… 最近よくりなっくすかふぇというのを見るし、 電源もありそうだしトプカ行きたいし行ってコード書きの続きするかな…

あああと一個宿題があったんだった

(21:48)


2010年
7月
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 29 30 31
1.shinh(2014-05-24 01:33) 2.Gimite(2014-05-24 01:33) 3.シンX(2014-05-24 01:33)
search / home / index

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

shinichiro.hamaji _at_ gmail.com / shinichiro.h