ToDo:
fsync を LD_PRELOAD で殺すとどうか、 という話になって殺してみたら結構良くなった気がする。 というか計測してみると fsync に40秒以上かかっていたりする。 ただ fsync しなくなるということは クッキーとかそのへんのデータがぶっこわれて起動しなくなるとかはありそうだから、 .mozilla バックアップはしておいたほうがいいだろうなぁ。
(00:53)
TCC はなんか Lua が動かねーよということだったので ちょこちょこ修正したら動くようになった。
(03:18)
ちゃんとありとあらゆるパターンのテストをやるべきだと思うんだよな。 たぶん必要なのは、 lib.c と main.c を用意して、
の4種類がきちんと動いてるか確認した上で、
の16通りのパターンで生成してチェックしたいと思う。 あとおまけとして lib.o main.o から作るケースも欲しいから、 そっちもあわせると 24 通りかねえ。
(17:54)
http://www.nicovideo.jp/watch/sm1273914
いいねえ。 ボーカルってよりはやっぱ楽器なんだよなぁ的な。 ミク製のゲームミュージックとか適当に探してみる。
http://www.nicovideo.jp/watch/sm1254297
http://www.nicovideo.jp/mylist/3531264
akita
(18:42)
なんかできねーなーと思ってたんだけど、 SHELL が /bin/zsh なのが悪いぽい。
% LD_LIBRARY_PATH=. SHELL=/bin/sh gdb ./main_gcc_tcc
などで解決
(21:07)
http://b.hatena.ne.jp/entry/http://blog.livedoor.jp/dankogai/archives/51190474.html
ネットワーク使えちゃうのが仕様、 っていうのは(いやライブラリ使うのが目的だというのはわかるけど) ちょっとそれどうなのよと思うなぁ… 自由に使える DOS の踏み台でしかない気が。
sandbox 自体は system call の回数が出てるし ptrace かな。
(00:09)
http://q.hatena.ne.jp/1136466767
を見て、僕の欲しいものは Brain Search と Room Search であるとか 思ってたら Brain Search の方は 4.1 ネタとして出た。
http://www.google.com/mobile/default/brainsearch.html
(00:18)
spysee のあの人は誰なんだというのは長い間疑問だったんだけど、 昨日画像をクリックしてみたら読めない言語のサイトが出てきて、 そこになんか shinh という文字列があったので疑問が解消した。
次の疑問は spysee は言語の検出もしてないんだろうかという。
(00:26)
https://bugzilla.mozilla.org/show_bug.cgi?id=421482
via http://mkosaki.blog46.fc2.com/blog-entry-861.html
そんなもんが悪かったのかー!
人生短いから読んでないけど、 この症状はしょっちゅう見るというか あまりにもどうしようもないので会社では linux の firefox 捨てた。
(01:03)
http://shinh.skr.jp/m/?date=20080525#p03
の時の手順でできないな。
extconf.rb 実行した時に bigdecimal でこける。 なんかよく見ると昔は手元の libruby をリンクしようとしてなかったのだけど、 今はしようとしていて、 CFLAGS の -m32 をひきつがないから、 って感じっぽい。
lib/mkmf.rb がどう CFLAGS を扱っているか… なんてことは深追いする体力もないしやめることに。
(01:10)
http://niha.tumblr.com/post/91457096/c
途中で cpp_akira さんは compile time の速度の話、 Cryolite さんは run time の話をしてるような気がするチックな。
compile time 減らす系の最適化は まぁ compiler が知っとくしかないよなぁ。
あとまぁなんにせよそんなところよりは お墨付とかインストールいらないとかの方が 圧倒的に強い気がする。
(19:16)
http://shinh.skr.jp/h/?HackTheCellPostMortem
なんか集めた方がいいかなーとか思ってたけど、 勝手に上げてくれてる人もいるし、めんどくさいし、 とりあえず適当にリンクとか足しておいた。 足し忘れなどありそうなので なんかある人は足していただけると幸い。
あとなんか感想としてはみんなすごいなぁというのが多くて まぁいつも思うことではあるけど今回は特に思ったなぁ。 比較的属性が共通しててでも違う仕事してる人が 多い感じだったのが良かったなぁと思う。
(20:48)
とりあえず現状で git push 。 今週末くらいにはなんとかしたいね。
今日わかったことは R_X86_64_GOTPCREL というのは shared object で -fPIC な時に必要だということと、 i386 だと rip 相対無いから R_386_GOTPC になるわけだけど、 PC 取ってくるのがあら大変ということを再確認というか
(22:44)
http://d.hatena.ne.jp/yupo5656/20060907/p1
のへんをどうぞ。この手の単語 (R_X86_64_GOTPCREL) は検索で来たりする人がたまにいたりするので… 俺とか俺とか…。
(22:49)
とかそろそろヨタ話ができそうなくらい どうでもいい知識が溜まってきた気がする。
(23:31)
http://shinh.skr.jp/h/?HackTheCellPostMortem
とりあえず、みんな、 「おおこんなこと思いついて俺 SUGEEE って思った瞬間があったけど、 数日経つとなんだ当たり前じゃんねと思い、 kik さんの説明を見るとああ俺はどうしようもなかったんだな…」 と思うというようなあたりの意識を共有できたかと思う。
まあでも kik さんも時間は湯水のごとく使ってるぽいんだよなぁ。 そのへん次回は彼の2倍程度は時間を使うことで対処したいと思う。
といいつつ、 hack the cell は期間が長いから有給取ってないんだよな。 なんていうか、趣味のプログラムに時間を溶かすことが 完全に習慣になっている人間としては、 3ヶ月から数百時間かそこら捻出することは造作もないことなんだよなぁと。 マラソンとか TLE とか ICFPPC くらい短いとそうもいかんわけだけど。
謎めき系
http://0xcc.net/pub/shibuyapm4/0006.html
について
の人に説明したところそれはお前のことだろと指摘されました。 件のプレゼンは現物では見てないけど僕の人生の指針となっていて、 これらの類型にはとてもなりたくない気がするので、 なるべく不明な点が無いように書いてみようと思うのであった。
とりあえず、 ^q-^m とかすると メモモードというかメールを書くモードになるのだけど、 これでまず subject を書くのが問題なんだよなぁ。 subject って途中か最後に書くべきもんだよね本来はたぶん。
いやでもね、
http://shinh.skr.jp/m/?date=20060518#p03
によると大々的に公開することに抵抗があるような 私的なメモであるというような位置付けが書いてあるわけだよね。
実際これを書く前の1年くらいは完全にどこからもリンクはってなかったんだけど、 リファラ経由でぐぐる様が来たりしてヒキコモリ体制が崩れていったんだよなたしか。
まあ僕がちゃんと書くことに関してメリットを感じればちゃんと書くかもですが、 あんま感じなければいい加減に書くのでそのへんは適当に。 気になったことについてのコメントとかはしていただけるとすごい嬉しいです。
ああそいえば今日も思ったんだけど、みんな質問しないよなぁ的な。 俺だけわかってなかったら申し訳ないなーとか思ってしまうので みんな聞いてくれるといいのにとか思うよね。 「何言ってるかわからん」とか質問の体をなしてない僕の質問に 丁寧に答えてくれた kik さんには感謝感謝でした。
あとまあ fixstars のみなさんは色々もう感謝感謝としか言いようがない感じでした。 感謝感謝。
(00:23)
8e5: 48 8b 05 6c 03 20 00 mov 0x20036c(%rip),%rax # 200c58 <_DYNAMIC+0x1c0> 8ec: 8b 00 mov (%rax),%eax 8ee: c9 leaveq 8ef: c3 retq
が正しくて、
75e: 8b 05 9c f8 ff ff mov -0x764(%rip),%eax # 0 <call_gmon_start-0x680> 764: e9 00 00 00 00 jmpq 769 <var_main+0x40> 769: c9 leaveq 76a: c3 retq
はまぁ色々おかしい。 やっぱ fPIC 的なのが無いと イマイチだなあ。 まあどうしても一段はませる感じにはなってしまうか
(15:54)
http://www.shimamoto-ele04.ed.jp/syokuin_zidou_top/syokuinkousei.htm
ふと目に入ったのだけど、 人数少なくね… 1学年100人くらいはいたように思うのだけど。
(11:51)
http://jijixi.azito.com/cgi-bin/diary/index.rb?date=20090326#p02
出てるのかあ。 買ってみようかなぁと思うけどPS2もテレビも崩壊してるなあ。
(12:27)
http://d.hatena.ne.jp/sugyan/20090326/1238007478
via http://d.hatena.ne.jp/kazuhooku/20090326/1238045916
末尾の空白がイヤなら
@s=("%02X")x16;printf"@s\n"x16,0..255;
で良いと思う。
なんかもちょい縮みそうな気はするけど Perl むつかしいな
(19:39)
しんどくて思考ができないけど 寝れないので新都社のマンガを適当に見てみる。 面白いの見つけた。
http://puripeni.web.fc2.com/index.html
人狼としてはまぁどうだろう、 実際の名ログとかの方がはるかに面白いという感じだけど、 途中から脈絡もなく踊ったりしてるのが面白すぎる。
(23:10)
http://longlong.way-nifty.com/blog/2009/03/700-c9db.html
もし良ければ軽く書いていただけるとありがたいかなぁと思います。
僕が最初に60倍ちょい越えの人がやってそうな工夫を 一通り紹介してみようかと思いますので、 基本的な工夫はナシですごい部分だけ書いてもらう感じでどうかな、と。
http://shinh.skr.jp/h/?HackTheCellPostMortem
↑適当にこんな話をしてもらえればいいかなーと 妄想で「何をするか」の欄を更新しておきました。 あと、現場はプロジェクタはあるそうです。
(01:42)
LLVM勉強会は遅れていって yarv2llvm から。
http://d.hatena.ne.jp/miura1729/20090323/1237779835
大変面白かったんだけど、 なんか色々ヘンにつっこんでしまった気がした。 疑問をすぐ聞いてたら なんかあら探しチックになってしまった感じで申し訳なかった。
Clang はまぁ案外面白いことやってるんだなぁとか思った。 tccparser とかもそうだけど、 C コンパイラライブラリって かなり長い間欲しかった感じがするんだけど、 というかそいうのがしたくて binary 2.0 なんちゃらとかで発表したりしたんだけど、 最近あんま興味ないんだよな。
SWIG生成なんかは超実用的だと思うし、 GCCXML 使った cableswig とか実際にあるわけだけど、 こうなんか現実的になりすぎちゃってねえという無いものねだり感が。 GCC plugin branch vs GCCXML vs Clang vs Doxygen とか オルタナティブも色々ある感じだしねえ。
あと LLVM 自体も類似技術との対決は面白いかも。 LLVM vs C-- vs TCG vs ... とかね。
呑み会は他に外せないのがあったので参加できず
(02:19)
_ kodera [ああやっぱり、２０人ともなると多少は何かあった方が良いですよね。 簡単にパワポでも用意しときます。すごい部分とか言う..]
_ shinh [ええ、結構時間も長いし、意外と話題も多そうですし、なんか資料的なのはあった方がいいかなぁと。 kik さんには頼んで..]
_ kik [プレゼン形式になってない文書はもうたくさん書いたので 新規で作るのめんどくさいんですが ホワイトボードはありますか？]
_ shinh [あ、はい、あれだけあればあの pdf で十分ではないかと思います。ホワイトボードは…まぁあるんじゃないでしょうかと思..]
_ wo [ホワイトボードはあります]
普通に log(n) 回の行列計算でいけるかなーとか思ったら kik さんが書いてた上に諦めていた。
http://d.hatena.ne.jp/kikx/20090321#1237632002
でぱっと見 kodera さんのがそれ実際にやってる感じに見えるけど、 えーと違うのかな。
http://longlong.way-nifty.com/blog/2009/03/hack-the-cell-0.html
なんか違う気がした。
ああそうか、たぶん、分割数が 4 なら、
と担当すればいいって話か。 ただこれは mt の更新行列がそれなりに複雑になっちゃうだろうから、 log(n) べき乗ができるならそっちの方が良さそうだなぁ。
次元の3乗のオーダーを log(n) 回ってそんなに大きくないんじゃないかな… とか思ったけど、 20000次元**3 を 128 並列でできるので、 62ギガ単位の話。 積和命令とかあった気がするし 62G clock でいけるの? よーわからんけど悪くて 124G clock だろう。 8コア使うって前提の話なので、 15G clock か。 今回の mt_kadai のサンプルくらいだと現実的じゃないけど、 もっと激しく大きければ案外いけるくらい?
眠いので根本的に色々まちがっていそうだ。
(03:00)
まあこの手のは基本的にはパズルでしかないので cell 自体の経験はあんま関係ないんじゃないかなぁ。
あたりがどっちかというとメインだった気がする。 even-odd の量をうまく散らすとかは重要だけど、 命令数たいして多くないから おおまかに把握するのにそんなに時間はかからないしなあ。 命令をうまく使って命令数減らすのも重要っちゃ重要だけど kik さん以外はたくさん減るのは見つけてない感じだよねたぶん。
一方 x86 とか経験がすごい生きそうだよなぁ。 herumi さんに勝てる気とか全然しない。
と書いてみて x86-64 でこいうコンテストとかも 割と面白いかもなーとか思った。 Core 2 Duo あたりで。 僕自信は勝負になる気がしないが。 誰かやらんかな。
(03:15)
分割数が 8 として、 num_rand が 8*10**7 だとして、 800 程度進める行列を普通に(log(n)とか考えずに)作るのは たぶん 640000 回ループ回す程度のコストでできて、
とかいう感じで分割すれば、 通常のループを 10**7 回と、 800 進める行列を 10**5 回かける時間で計算できるんじゃないかなぁ。 そしたら 10**7 回のループが律速な感じだから だいたい 8 倍になってる気がするなぁ、 とか思ったけど定かではない。
(03:30)
これで8倍になるんだったら SIMD ったら shufb, selb, rotqw* あたりが消えたりするのかな。 というかそれが
http://pc11.2ch.net/test/read.cgi/tech/1232817361/581
が言っていたことか。やっとわかった。
shufb とかも減れば odd も減りそうだけど、どうなんかな。 だとすると SPU 1個でももっとフザけた倍率出たりするのかな?
(03:37)
http://d.hatena.ne.jp/firewood/20090322/1237659723
いいかげんな正規表現がそれなりに有効というのはとても同意… 元の正規表現で実用上一番問題なのはプラスが入ってないこと、かなぁ?
とかはいいとして、
http://blog.livedoor.jp/dankogai/archives/51189905.html
の From: Anonymous <nobody@example.com> を Perl の正規表現ならできる…っていうのは 実物がもしあるんなら見てみたいな。 自分では全然知らんけど、聞きかじった知識を元に考えると大変そうで、 結構とんでもないことになってそう。
(04:27)
とりあえずやらにゃならなさそうなのは、
あたりか。
(12:51)
| 前 | 2025年 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扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。
_ kosaki [ext3のordered modeはなにせorderedなので、fsyncよりも前に発行された全IOの書き出しを待つ..]
_ shinh [suck by design ですねえ… ext4 とかだと良くなってたりするんでしょうか。それか XFD とか R..]
_ kosaki [Ted Tso 曰くext4にこの問題はないそうです。ただ、アプリ屋さんはあと３年ぐらいはext3を無視するわけには..]
_ shinh [なるほど。 ext4 に移行してデータがなんかおかしくなるかもな確率は低いけどダメージが大きいリスクと、 fsync..]