ToDo:
割と面白いかなぁ。 保存しないと反映されないんだけど、 html なんだからもうリアルタイムで更新してくれてもいい気もするな。 JS とかは保存を待って欲しいかもしれんが。
縦書きを transform でやってるのがあったので、 適当に flexbox でもやってみた。
Firefox だとびろーんと長くなった、が気にしない方向で。
(00:37)
つまり僕の転職候補会社が一つなくなったということだけど、 元々その可能性はとても低そうなので別に関係なかった
いや、しかし、これで楽天が大成功しちゃったりすると、 他の企業もマネしたりして、 つまり僕の転職候補会社が減っていく、 そういうことになると大変悲しいのだけど、 元々その可能性はとても低そうなので別に関係なかった
(23:23)
http://d.hatena.ne.jp/nurse/20100702#1278054508
CGI 好きなんだけどなぁ。
Process isolation というのは本当にいいもので、 つまりこう Ruby がクラッシュしようが メモリバカ喰いしようが、 そのプロセスさえ死んでくれればいいわけで、ねえ。
ゴルフ場はなんとなく FastCGI だけど、 正直 CGI の方がいいんちゃうかなーとかたまに思う。 なんかたまにメモリ大量消費してて、 よくわからん。
しかしまぁ、僕とかは ruby で web のなんか作る人間としては、 それこそ CGI.rb にそれなりに我慢ができる程度に 圧倒的にライトユーザなので、 まぁ意見としてはどうでもいい層なんだと思う
(23:56)
っていうジャンルがあるんだなぁ。 よく考えるとメインなノートPCのキーボードとかいらんわけだし、 もうこういうのでいい気がしてきた。
要求としては
この条件を満たしてなるべく安いものならいいと思った
(12:30)
dev channel 出てるなーということで入れてみた。
とりあえず linux は paged media 入ってるなぁ。
Win と Mac は間に合ってないっぽいな。 ちゃんとテストせんとなぁ…
(15:22)
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)
http://www.pps.jussieu.fr/~jch/software/polipo/
という cache する http proxy があるらしい。
filtering もできるっぽいから、 mod_python_filter とか使うのやめてこっちでいいかなぁ。
(16:13)
そうか $ をいじるという手があったかー
僕は fromInteger いじれるといいのかなぁとか思ったけど、 instance Num すると + を再定義せざるを得ないっぽいので どうしたもんかーという程度でとまってしまった
(06:39)
pm の man はあったものの w3mman で見れなかったので修正
http://github.com/shinh/w3m/commit/b9ad76673b43feba10f4d968948c8e44588f8334
(06:44)
すっかり忘れてた… 今からでもなんか書こう。
バイトしてた時の最初のプロジェクトは 大変社会勉強になるコードだった。
less とかで読んでいると、 どうも 2 行に 1 行空行が入っていて、 ヘンな style だなぁと思ったのだけど、 実は 20 段くらいネストしてるから 空白だけで 80 column 越えしてたのだった。
そのネストした中身はコピペな感じなコードなのだけど、 なかなか内容もためになった。
どういうものかということで一つ覚えているものを。 直線がたくさんあって、 その直線群、つまり
struct Line { float start_x, start_y, end_x, end_y; } vector<Line> lines;
とかいう lines があったとして、 その lines がループを形成しているかを判定したいらしい。
どうやってやってやるかというと、
複雑なコードの管理能力と、問題解決のための独創的な発想の2点で、 そのコードを書いた人は頭いいと思った。 つまりこう、頭は悪い方がいいのだなぁと勉強になった。
(07:22)
http://d.hatena.ne.jp/yshl/20100704#1278255925
おおありがたや、ということで適当に
http://github.com/shinh/w3m/commits/master
(00:45)
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 されているのよね。
なんか話としては
などなど。なんか C++ ダメなんじゃないかと思った。 0x とかで解決されてるよ! とかだったらすいません。
(02:22)
でその議論の結論としては
#include <stdio.h> struct S { S(const S& s) { } }; int main() { // copy コンストラクタを定義たせいでデフォルトコンストラクタが無い時は //S s; // こうすればいいよ! S s(s); }
(02:32)
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)
_ kosaki [なんかどこかで聞いたことある話だと思ったらmameさんがズバリ書いていてくれた。なんというエスパー]
_ shinh [おおたしかに再ヒットしてますね面白い。ただ、 linux+glibc だと後半半分くらいの overlap 、つまり..]
_ Rui [CALLとRETをペアにするほうが速いというのはどこかで読んだなーと思ったらAMDの最適化マニュアルでした(*1)。..]
_ m.ukai [> call pop 今時は平気で最適予測できると思いますが、return stack buffer を実装した初..]
_ shinh [Rui さん m.ukai さんコメントありがとうございますです。 ご指摘の通り、 -mtune= で call/..]
あの英語は失笑を招くほどひどいらしい。
みんな英語うまくていいなぁとしか思えない。
や、日本ぽい発音てのはそだけど、 どう考えても通じると思われるので別にいいじゃんね…
あれがダメだっていう人はこう、 インド英語とかもダメってことになると思うんだよな。
なんか楽天に関しては色々思うことが混じっていると思う。
最後の意味でこいう意見はとてもこわい。
http://d.hatena.ne.jp/nishiohirokazu/20100707/1278509600
僕個人はさっさと転職を選択すると思うけど、 しかし仮にうっかり愛社精神が強くあったりしたら悩むと思うので、 英語ができないくらいで仕事できないとか言われることになって、こわい。
ところで、よく TeX とか C とか人を長期に渡って 苦しめててひどいとか言うけど、 英語の方がよっぽどひどい言語と
(00:59)
なんか C はいいものだけど、 ハードウェアってそれなりに変わったらしいし、 C の守備範囲でもちょいなんか無いもんかねみたいな話を よくしたり聞いたりするんだけど、 なんか機能で考えるより何が実装できればいいかを考えればいいんかな。
アセンブラや言語拡張無しで、
このあたりかなぁ。
(02:05)
_ ささだ [backtrace? stack frame に対する操作ですかね.一瞬バックトラックかと思った.大体同意します...]
_ shinh [x86-64 は stack frame 無いので言語なりライブラリがそいう抽象化レイヤーを提供してくれないとどうに..]
_ n [時間をかけた完璧なsimd化と、そのキャッシュがあれば十分な気がします>ベクトル命令 最適なメモリアラインがCPUア..]
_ shinh [SIMD って完璧にできるんですか? なんか画像処理とか暗号とかの最内ループ付近は結局アセンブリ手書き的な感じなのか..]
_ shinh [あ、あともちろん「ほとんどのケースでは C で十分である」的なことはその通りだと思います。ただ現状の C は高級アセ..]
http://shinh.skr.jp/dat_dir/mederu/041.html
ここで「たぶんできそうげ」と書いた、 アルファベットだけの Perl で任意コード実行だけど、 今考えると比較的簡単にできるのであった。
同じく quine も書けると思う
今度なんか書く
(02:35)
なんで駒場に行かにゃならんの… ということで雨もふるし大変うざい選挙になってしまった。 どうも期日前投票するべきだったみたいだ。
好きでない共産党にわざわざ投票しに行ったのに 落選してしまったのでかなしかった。 タリーズめ…
しょうがないのでついでになんかしようとマンガを 読んだり買ったり。
読んだ:
ドリフターズは普通に面白そうだなーと思った。 ローマとカルタゴの人を知らんかったのでちょっと歴史の勉強した。
眠れる惑星。 あいかわらずストレートに都合のいいエロマンガかく人だなぁとか思った。
打撃天使ルリ。 3巻で終わってたのかー。 1巻あったら買ったんだけどな。
殺しや1の人とのぞき屋は同じ作者だったようだった。
罪と罰はなんか時代ずらしただけじゃなくて、 ソーニャの立ち位置とか全然違うっぽい。 なんかラスコーリニコフ役から信念が感じられないのがいけてないなぁとおもった
カイジ。つまり福本先生この話実体験ってことすか…的な
あと忘れたけどもろもろ。 燃えよペンってもっとぶっとんでた気がしたんだけど、 今見るとなんかそうでもない気がしてしまった。
買った:
地雷震1。最初の方はどうしようもなく救われなくていいよね。 そういえばウシジマ君もなんか少しいい人になってて そのへん地雷震ぽい気がちょっとした。
ジャぱん18 はですよがついてる話を読んでおこうかなぁとか思って買った
初期のURASAWA 。激しく読んだことあった。
劇画自民党総裁。勉強になった。
まるごと西原理恵子。 西原理恵子のマンガの読み方としては これはすごくいい売り方な気がするなぁ。
恐怖新聞。 うしろの百太郎の方が事実として押しつけてくる感が強い感じなのかな。
そんなことよりやりたかったことはあるはずなんだけど無駄な日曜になった
(23:53)
http://twitter.com/lyrical_logical/status/18776878242
芸風的に雌豚先生復活とかだと嬉しいなー。 動画丁寧すぎるのがそれっぽくないけど。
(10:09)
C++ で書いたらだいぶ速くなった。 20-30倍くらいか。
基本正規表現だけだからこんなに速くなると思ってなかったんだけど、 まぁ Ruby の方のコードは色々適当なのが悪いんじゃないかと思う。
で
all: "$(loop0)" loop3000000: "DONE\n" loop(\d+): loop$(add($1,100)) #include "std/num.wake"
とかが 2 秒とかかかってて、 ちょっとまだ遅すぎるよなーという感がある。 16kHz とかくらいか。
ターゲットが増えると遅くなるってのはいけてないので、 なんかそのへんなんとかなるといい。
二つほど方法はあって
とかかなぁ。
正規表現の合成って特に後方参照的な意味で 難しそうな気がするけどどうなんだろうな。 普通に \1 とかの番号を振りなおすだけでいいのかな。 とりあえず \10 とかは使えるんだなーと確認した。
うーんでも trie かな
(13:59)
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 は何故 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)
perftools でプロファイル取ってみたところ、 正規表現とかでは全然なくて、 malloc 多すぎとかだった。 とりあえず string::reserve 呼ぶとだいぶ速くなった。
あと tcmalloc 使うとだいぶ速くなる。
ベンチマークは大事だなぁと思った。
で、前回の話から考えると、 std::string じゃなくて自分で string 作った方が速くなるんないか…
(18:02)
libpcre の symbol 取れねーなーと悩んでいた。 profile の末尾についてる /lib/libpcre... とかを /usr/lib/debug 以下のものに置換すればとりあえず取れるみたいだ。
inline 展開のせいでよくわからんのだけど、 たぶん、
って感じっぽい気がする。 とりあえず後者は簡単に減らせるはずだ。 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_exec が遅かったみたいだった。
RE2 はどうかなーと思ったんだけど、 backreference が無いみたいなので論外だった…
Irregexp とか YARR とか使ってみるという手もあるんかな。
ぱっと見では YARR の方が切り出しやすそうな雰囲気かなぁ… と思ったけど wtf とかに依存してやがるな。
Irregexp にするか… とか思ったあたりで何やってるんだろうと思いはじめてきた。
(20:59)
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) になるのか。
で…
2.77618e-13*x^2.55 の方が 2.10854e-10*x^2 よりどう見てもマッチしてるな。 特異的って感じもないと思う。
まぁ Haskell とか不思議の塊なので、深く考えるのはやめ。
で、メモリ。
うーん O(N)。
まぁ Haskell とか不思議の塊なので、深く考えるのはやめ…
(02:10)
二つ目のグラフの a == 0.668326 だそうです。 そしてメモリの縦軸は kB 。 つまりメモリ使用量が 668 Bytes ずつ増えていく計算になるわけですが…謎。
もう少し上まで
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%)
a = 0.642804 +/- 0.007101 (1.105%)
ソースコード
http://github.com/shinh/test/commit/79d93f47d025f841ee9a7639bf3b493d918b86b0
(02:27)
名前は
のでちょうどいいと思った
あと一日中雌豚先生の作業用 BGM 聞いてた結果、 たしかに違うかなーと思った。
(02:42)
書いた記憶があるのにどこにもないなぁと探しまわった。
見つかった…
http://d.hatena.ne.jp/shinichiro_h/20100121#1264012341
検索用: befunge brainfuck bfint.bef brainfuck.bef
(02:51)
たいしたことじゃないけど
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)
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)
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%)
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"
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%)
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++ ではどうか。
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! すごいです!!
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; }
これまでのあらすじ:
Ruby すごくね
(14:57)
これは GC のある言語に大変厳しいベンチマークなので、 公平性には欠けまくりだと思う。
なんでかっていうとメモリ使用量が増えるばっかりで、 全然 collection されないから。
聞いた話によると、コンパイラとかはこいう挙動をする、 GC 泣かせなアプリの一つらしい。 つまりソースコードを読んでがーとデータ構造作るんだけど、 作るばっかであんま解放する物は無い、というような。
(15:01)
なんか 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 とかをチラ見するに、
で、定数ずつ 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 の部分を適当に調整すると色々変わる。
グラフはこんな感じ
つーわけで、 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)
以下は、左から、 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)
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)
_ k.inaba [Haskellのは、自分のとこではO(N^2.6)とか全然再現せず普通にO(N^2)に見えるのでという理由と、とりあ..]
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)
http://d.hatena.ne.jp/nishiohirokazu/20100721/1279687613
つまり kinaba さんの説通りっぽい感じだなぁ。
まとめておくか
あたりでみんな O(N^2) 以上の計算量になってたって感じか。
D に関しては O(N^3) なんだけど、 GC の頻度少ないので、 O(N^3) の係数が大変小さくて 間くらいのオーダに見えた、と。
正直色々やりたいことある時期に 比較的どうでもいい議論に時間を使いすぎた感もあるけど、 しかし GC は結構むつかしいもんだなーという勉強になった。
そういえば Haskell は stack が O(N) になっちゃうのは避けられないんだろうか。 うーん僕の脳内 Haskell 処理系では無理げだな。 つーことは、無限リストの 1億要素目をいきなり取り出すとか だいたい無理みたいなことになるのかあ。
(04:06)
_ shinh [ああなるほど。そういう意味であれば、 Haskell のコードは普通に動的計画法で書いた時のコードに近いものになって..]
_ シンX [ああ、仰せのとおりです orz 多倍長加算のコストを途中で忘れてました。その計算量で良いです。 ところで、計算量理..]
_ shinh [ちなみにサイズ N のスタックになってるのは、 遅延評価された N 番目の fib を取ろうとする => あっまだ..]
_ shinh [でまぁプログラマは遅延する必要無いのはよく知ってるのでこれ正格評価してくだっせーと教えてやれば stack 使わんよ..]
_ シンX [理解しました。解説ありがとうございました。というかわざわざすみません m(..)m]
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)
http://build.webkit.org/results/Windows%20Release%20(Tests)/r63992%20(1883)/fast/text/
なんでまだコケてるんだよボケ! と思ったら r63992 とかで全然追いついてないのか…
この win bot がぶっこわれてる状態がずっと続いてるってのは Apple の人とか困ってないのかな…
もう体感で 2,3 ヶ月くらい壊れてる気がするが 実際どのくらいだろうな。
(07:15)
日本語化されたとのことで遊んでみた。
一度外したけど、エミリオミハイロフを当てられて心底びっくりした。 軍人かどうかはむつかしいなーと思った。
JB-5th は当てられなかった。 まぁ結局誰も入力したこと無さげだ
(23:08)
なんかボタンが押しっぱなし状態になっていたり、 全然押せない状態になったり、 とにかくどっちかに固定されてしまう。 「macbook トラックパッド」で「故障」が suggest されるあたり、 よくあることなのかもしれない。
http://haru3.cool.coocan.jp/archives/pc/mac/08-187-0057.php
になんかなおしかたが書いてあるのでやってみよう…
(22:30)
トラックパッドのボタンが押しっぱなしになる問題は、 バッテリが膨らんでいるせいだと判明した。
つまり後ろから全力でバッテリが押してやがるから、 ボタンがおしっぱなしになる、と。 なるほどねえ。
バッテリがこの位置になかったら使えてたってことだよなーということと、 しかしこの位置になかったら気付かんくて危険だよなーということと、 を思った。
でまぁこの膨らんだバッテリは、 十分膨らんでいるために、もう中に入らないのであった。 つまりもうまっくちゃん動かないってことなの… と思ったけど、よく考えればバッテリはずせば動くのであった。
ただまっくの電源ケーブルって異様にアッサリ抜けやがるで有名なので、 ケーブル抜けるだけで電源断ってのはキツいか。 まぁいずれにせよ apple store に持って行ってみよう
(23:11)
も壊れたっぽい。
みんな夏ばてかのう
風は出るんだけど冷たくない。 死ぬかと思ったけど窓開けて扇風機まわしたら 普通に寝つけた。 まぁ消してから寝てもタイマーで切れても大丈夫なんだし死なないか…
(06:57)
http://shinh.skr.jp/m/?date=20090727#p01
あれから1年たってる!
今一つ覚えてないけど、 なんとなく思い出せるから久しぶりにいじってみるか…
メモを見るに PLT の方が課題って感じ?
(07:32)
どうも俺は Mach-O について微妙に知ってるのに、 全然作ったツールとか出てこなくておかしい。 結局見つけたのはこれくらいか
http://spreadsheets.google.com/pub?key=pcoKcHzxsAsgfZ3aSIeDdcQ
(08:31)
全体的に面白そうだったから行きたかったな。
(22:24)
クーラーこわれてる部屋は暑すぎるので とにかく家にはいられないということで 割とさっくり行く決意ができた。
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 とかも それまでに 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 |
全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。
_ 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-..]