ToDo:
適当に kik さんのコードを GCC にコンパイルさせた結果を 僕のアセンブリ再配置マッシーンにかけてみたら遅くなった。 まぁ GCC は意図があってというか 命令の配置と協調してレジスタ配置してるわけで、 レジスタ配置を固定して命令配置いじっても速くはならんわなぁ…と。
で GCC の吐いたコードを仮想レジスタ作って SSA にしてみて (レジスタ1000個くらい必要だった)、 それを適当なヒューリスティックスで 実際のレジスタ割付しながら命令を配置していくものを書いてみたら、 レジスタ250本くらい必要だった上にさらに遅くなった。
GCC は偉いなぁと思うと同時に、 問題のドメインを理解してる人間による レジスタ配置は最強だなぁと思った。
じゃあ表題の倍率は何かというと、 volatile つけたら速くなった ⊂( '-')⊃
--- mt_mine_orig.c 2009-05-18 06:49:16.000000000 +0900
+++ mt_mine.c 2009-05-18 06:55:06.000000000 +0900
@@ -86,6 +86,7 @@
}
typedef vector unsigned long vul;
+typedef volatile vector unsigned long vvul;
typedef vector unsigned char vub;
static vul mt_bs[32][5] __attribute__((aligned(16)));
@@ -166,39 +167,39 @@
};
vul sum = {0, 0, 0, 0};
- vul s0_0 = mt_bs[0][3];
- vul s0_1 = mt_bs[1][3];
- vul s0_2 = mt_bs[2][3];
- vul s0_3 = mt_bs[3][3];
- vul s0_4 = mt_bs[4][3];
- vul s0_5 = mt_bs[5][3];
- vul s0_6 = mt_bs[6][3];
- vul s0_7 = mt_bs[7][3];
- vul s0_8 = mt_bs[8][3];
- vul s0_9 = mt_bs[9][3];
- vul s0_10 = mt_bs[10][3];
- vul s0_11 = mt_bs[11][3];
- vul s0_12 = mt_bs[12][3];
- vul s0_13 = mt_bs[13][3];
- vul s0_14 = mt_bs[14][3];
- vul s0_15 = mt_bs[15][3];
- vul s0_16 = mt_bs[16][3];
- vul s0_17 = mt_bs[17][3];
- vul s0_18 = mt_bs[18][3];
- vul s0_19 = mt_bs[19][3];
- vul s0_20 = mt_bs[20][3];
- vul s0_21 = mt_bs[21][3];
- vul s0_22 = mt_bs[22][3];
- vul s0_23 = mt_bs[23][3];
- vul s0_24 = mt_bs[24][3];
- vul s0_25 = mt_bs[25][3];
- vul s0_26 = mt_bs[26][3];
- vul s0_27 = mt_bs[27][3];
- vul s0_28 = mt_bs[28][3];
- vul s0_29 = mt_bs[29][3];
- vul s0_30 = mt_bs[30][3];
- vul s0_31 = mt_bs[31][3];
- vul t0_0 = mt_bs[0][4];
+ vvul s0_0 = mt_bs[0][3];
+ vvul s0_1 = mt_bs[1][3];
+ vvul s0_2 = mt_bs[2][3];
+ vvul s0_3 = mt_bs[3][3];
+ vvul s0_4 = mt_bs[4][3];
+ vvul s0_5 = mt_bs[5][3];
+ vvul s0_6 = mt_bs[6][3];
+ vvul s0_7 = mt_bs[7][3];
+ vvul s0_8 = mt_bs[8][3];
+ vvul s0_9 = mt_bs[9][3];
+ vvul s0_10 = mt_bs[10][3];
+ vvul s0_11 = mt_bs[11][3];
+ vvul s0_12 = mt_bs[12][3];
+ vvul s0_13 = mt_bs[13][3];
+ vvul s0_14 = mt_bs[14][3];
+ vvul s0_15 = mt_bs[15][3];
+ vvul s0_16 = mt_bs[16][3];
+ vvul s0_17 = mt_bs[17][3];
+ vvul s0_18 = mt_bs[18][3];
+ vvul s0_19 = mt_bs[19][3];
+ vvul s0_20 = mt_bs[20][3];
+ vvul s0_21 = mt_bs[21][3];
+ vvul s0_22 = mt_bs[22][3];
+ vvul s0_23 = mt_bs[23][3];
+ vvul s0_24 = mt_bs[24][3];
+ vvul s0_25 = mt_bs[25][3];
+ vvul s0_26 = mt_bs[26][3];
+ vvul s0_27 = mt_bs[27][3];
+ vvul s0_28 = mt_bs[28][3];
+ vvul s0_29 = mt_bs[29][3];
+ vvul s0_30 = mt_bs[30][3];
+ vvul s0_31 = mt_bs[31][3];
+ vvul t0_0 = mt_bs[0][4];
vul t0_1 = mt_bs[1][4];
vul t0_2 = mt_bs[2][4];
vul t0_3 = mt_bs[3][4];
(07:01)
プログラム書いてる子は自然言語処理系のもの書くのが 難しいことを知ってるからあまりその手のものを バカにしたりはしないんじゃないかと思う。 でもコンパイラが難しいことを知ってるのに GCC をバカだと言ってしまうのは。 レジスタ配置で負けたので反省しないといけない
(07:06)
#GC::Profiler.enable
a = Array.new(1000000){'a'};
puts 'array nilled';
a = nil;
#a.clear
GC.start;
count = 0;
ObjectSpace.each_object{count += 1};
IO.popen('free'){|p| puts count, p.read}
#GC::Profiler.report
via http://redmine.ruby-lang.org/issues/show/649#note-8
i@uco ~/src/ruby-1.9.1-p0> ./miniruby_orig leak2.rb
array nilled
1628
total used free shared buffers cached
Mem: 516296 446072 70224 0 10128 262248
-/+ buffers/cache: 173696 342600
Swap: 0 0 0
i@uco ~/src/ruby-1.9.1-p0> ./miniruby_new leak2.rb
array nilled
1627
total used free shared buffers cached
Mem: 516296 446336 69960 0 10144 262248
-/+ buffers/cache: 173944 342352
Swap: 0 0 0
1000000 の方は普通に漏れてないし。 でもなんか 1 object 減ってるなぁと調べてみると 'array niled' って文字列の方だった。
そして x86-64 だとむしろ miniruby_new で 1000000 オブジェクトの方が漏れるぞ論外だ… まぁ x86-64 でだめなのはまぁありそうな話だけど。
もちょいたくさんベンチできるテストケースが欲しいなぁ。
(08:02)
even 957 命令。
a 65 ai 1 and 33 cntb 160 sumb 80 ori 8 selb 165 xor 440 nop 5
odd 882 命令。
rotqbyi 70 stqr 160 lqr 167 hbrr 1 brnz 1 rotqbii 198 lnop 28 shufb 40 stqd 71 lqd 86 shlqbii 60
で結果は、 126.628 倍。
ORIGNAL: sum=3c927c56, 292970508 ticks MINE: sum=3c927c56, 2313630 ticks
うーんこれは狂ってるなー。 よくこれで優勝したなぁ。 コンパイラが吐いてるコードをちらちら見ると どう見ても最適とは言いがたい。
まぁそれより even/odd のバランスが悪いし nop も残ってるし。 even 957 命令に律速されてるとすると、 nop/lnop 削って even/odd にバランス良く振るだけで 903命令134倍とかになる。 まぁそこまで理想的にいかんとしても、 どう見ても不要な命令の削除だの、 レジスタに状態を置くだのすればもっといくわけで、 少なくとも 135 くらいは行けてたんじゃないかなぁ。
kodera さんの方は、二重ループになってて計算しずらいので、 結果から逆算すると、 1007.6 命令らしい。
120.705 倍。てか ORIGINAL の方も変わるのね。
ORIGNAL: sum=3c927c56, 294032967 ticks MINE: sum=3c927c56, 2435961 ticks
僕は 1270 命令らしい。
http://shinh.skr.jp/m/?date=20090307#p08
ORIGNAL: sum=3c927c56, 293506387 ticks MINE: sum=3c927c56, 2973408 ticks
(10:18)
http://codereview.chromium.org/99143/diff/8054/7059
http://twitter.com/niha28/status/1818969913
この diff が欲しいですよねえという
(10:27)
http://hujita.sakura.ne.jp/log/eid225.html
何度も聞いたのに歌詞がさっぱりわからんと思ってたら、 そうとう意味不明な歌詞だったんだなぁ。
(12:32)
GCC いじりは思ったより速くできてしまって、 飛行機の中は暇だったので映画とか見てた。
タイタニック: 面白くなさすぎて面白いレベル。この内容でなぜ主人公がヒロインの命の恩人なのかなど、全体的にまぁひどかった。
博士の愛した数式: 小説の雰囲気がぶち壊されていると感じた。
荒野の用心棒: まぁなんか面白かった。後半に入る前になんで主人公はみすみすボコられに行ったのか…というのが謎ではあった。
24: まぁまぁ面白い感じで進んでいた。
で、 GCC いじりをした結果は作ったバイナリが SEGV してたのでがくり
(00:18)
ぎぎぎ。メモ。
44f283: c7 44 24 08 00 00 00 movl $0x0,0x8(%rsp) 44f28a: 00 44f28b: 48 8b 44 24 08 mov 0x8(%rsp),%rax 44f290: 48 83 c4 18 add $0x18,%rsp 44f294: c3 retq
あまり簡単ではないなぁ。
(13:34)
http://d.hatena.ne.jp/otsune/20090514/SocialbookmarkIsMicroblogging
「反論するコストが高い・面倒」ではない、 ってのはまぁ、そうかなぁと思う一方、 「はてブには反論できない！卑怯だ！！」 ってのはまぁなんかわからんでもないなぁと思う気がする。
で、なんでわからんでもないなぁと思うかを考えてみる。
なんか考えをまとめるのがめんどうになった。
1つ目と4つ目はありそうだなと理解はできるけど、 個人的には思ってないな。 それがなんでかというと、 考えるのがめんどくさい
でまぁ、4つ目のようなのを考えると、 相手がどういう人か入念に調べてから反論したい派の人 (というのがいるのかは知らんが)は コストが高いと考える可能性はある、かな。 まぁ「相手がどういう人か入念に調べてから反論したい派」 というのが実在するのかもよくわかってないのでどうでもいい。 まぁでもなんかいそう。
(15:47)
TODO は比較的減ったとおもう。
最近は
なにかあまり減っていないな
(16:03)
そういえばだいぶ前にカジノに行った。
ショートスタックで入るとあまり面白くないなぁという感じだった。 全体的にヘボプレイだったけど、えらい固くプレイしたら 運が良かった時が何回かあって$70増えた。
(16:08)
http://cvs.m17n.org/~akr/diary/2009-05.html#a2009_05_13_1
なんでこれでできるのかなーと思ったら、 いつのまにか nil だったらその要素は落とす、 ってのが入ってたっぽい。それは良いように思うけど、 連続してる場合に区切るケースはなんか 状態の保持のしかたがマジカルな感じで、 イマイチ嬉しい感じがしないかなぁ…という。 あと連続しないと仮定してもフリップフロップした時点で負けた感じが少し。
(15:11)
http://japan.cnet.com/blog/kenn/2009/05/01/entry_27022150/
via http://practical-scheme.net/wiliki/wiliki.cgi?Shiro&l=jp
なんというか、さみしい話だなぁと思った。
そいや kocha って結構使われてた気がするなぁとか思ったけど、 あんま使われてなかった。
http://www.google.co.jp/search?q=%22powered+by+kocha%22&hl=ja&lr=lang_ja&safe=off&filter=0
なんか改変して使ってもらってるとかあった気がするんだけど、 そいうのは powered by 消えてるだろうし探すのだるいな
(14:06)
http://www.nabble.com/-ruby-dev:38392--Enumerable-gather_each-td23457727.html
via http://cvs.m17n.org/~akr/diary/2009-05.html#a2009_05_09_1
なにやら面白い議論になってるなぁ。
gather という名前よりは aggregate の方が良い気もするけど、 ゴル略的になのが略ではある。
SQL の GROUP BY なんかは aggregation って言われるわけで、 感覚としてはあのへんに近いイメージがなんとなくあるよね。
http://www.google.co.jp/search?q=select+%22group+by%22+aggregation&ie=euc-jp&oe=euc-jp
あとなんか現状の提案だと直前も直後も両方分けるようなのが無さそうだなぁ。 どいうのかというと、 C 言語のソースから struct だけ切り出してきて他の部分は全部捨てる、とか。 そいうのも似たような API でやれんもんなのかな。
(14:56)
http://d.hatena.ne.jp/nishiohirokazu/20090512/1242073617
をチラっと見て。あまり関係ないことを。
ごきぶりポーカーの問題点は単に最弱を決めるゲームだからだと思う。 僕的に似たような分類のゲームのコヨーテの方がはるかに面白い。
まぁ回すメリットがありまくりなのはその通りだとして、 まぁ割と色んな心理的なやりとりがあるにはあるんだよな。
ごきぶりポーカーってゲームは要は死ななきゃ勝ちで、 死なない方法は大別して二つあって、 回した相手がさらに回してくれるか、 全く回ってこないうちに誰かがダウトして終わるか、 のどっちかで、 前者は速く回してもらわなければならず、 後者はなるべく後にして欲しい。 基本回す系の場では前者になれば良く、 基本回さない系の場では後者になれば良い。 前者になるには、 「この人は回してくれるから自分は危険にならない、この人に回そう」 と思われればいいので、序盤にあんまりダウトしなければいい。 後者になるには、 「こいつはダウトしてくるしその精度もいいし危険だ、他の人に回そう」 と思われればいいので、序盤にキチンとダウトしていけばいい。
で、問題は、どっちのプレイスタイルも、やってて全く面白くない。
まぁ個人的にはむしろわざとカードをゲットして 特定の相手をハメるとかやるくらいの方が面白いと思うんだよな。 勝ちにこだわるゲームというより盛り上がれば良いパーティゲー。
(15:08)
http://niha.tumblr.com/post/106249503
どうでもいいらしい。 圧倒的に重要な要素の一つだと思うけどな。 少なくとも、全体の設計が崩壊してるとか、 そもそもプロジェクトの方針が狂っているとか、 そいうマクロなレベルじゃなくて、 ミクロなレベルだと最重要級だと思うけど。
はてさて。
あまり思いつかないので、 名前で抑制できない種類のダメコードを考えてみる。 僕が見たことあるのを適当に思いだすに、 論外すぎるコードはまぁどうしようもないなぁ。
など。まぁこのへんは御愁傷様でしかないというか、 まぁこのレベルの人はアドバイスとか聞くような アレじゃないと思うのでどうしようもないんじゃないかと思う。 たぶん。 個人的な記憶だと C++ 書けると主張してるけど、 セミコロン無いというコンパイルエラーを 何度もわからんと言って聞いてくるとか。
対処について考えると、 まぁコンパイル通らないのは「きれいな」とかいう以前に 「コード」かどうかあやしいので良いとする。 スタイルはまぁ、統一していいんならちょっとスクリプト書いたりすれば それなりになんとかなると思う。 アルゴリズムが論外なのは、 まぁ生理的に不愉快な気持ちになるけど案外読めたりはするよなぁと思う。 案外問題なく動いたりもするし。
まぁ対処は元の話と関係なかった。
あとは、テスト全くない、理解が難しいところにコメントが無い、 なんかもキツめかなぁと思う。 このへんのレベルの人はアドバイスとかでなんとかなる、かなぁ？ こいう部分とか名前重要とかは、コードレビューやってりゃ かなりの部分防止できるんじゃないかなぁと思う。
他になんかあるかなーと考えると、 まぁやっぱマクロな部分しか思いつかんかな。 大きいコンポーネントはまぁ複雑になっちゃうのはしょうがないし、 なんか名前重要みたいな一言である程度含蓄のある 一言みたいなのはあまりなさそうだな。 まぁ大きいコンポーネントをちゃんと作るとかでも ある程度名前重要だと思うけど。
(15:39)
こいうのを買うと、 USB 機器が充電できつつさらに電池も充電できる、 のだと思う。 デジカメを使ってみたり、 アンドロイドの GPS で行動記録とか取ってみてわかったのは、 電力供給重要だなぁということなのだった。
世の中には USB 髭剃りというのもあるらしいので、 このへんもあるとバッテリ一つで旅行行くことができるんじゃないかなぁとか思う。
http://plusd.itmedia.co.jp/pcupdate/articles/0508/22/news014.html
(18:21)
http://cvs.m17n.org/~akr/diary/2009-05.html#a2009_05_07_2
こいうのは僕の長年のテーマではあるような、気がする。
この手のものの解決としてフリップフロップ演算子があるわけだけど、 まぁ、このケースはまぁ、ループを2重にすべき場所なんじゃないかなぁと漠然と思う。
io = STDIN
l=io.gets
while l
w = l[/\w+/]
a = [l]
while (l=io.gets) && /^#{w}/ =~ l
a << l
end
puts a.sort
end
この手のコードで気にいらないのは、 l = io.gets が二箇所あることだと思う。 あとこの手のは a << l 的なのが二箇所に出ちゃうケースも多いんだよなぁ。 こいうの(イマイチ共通の問題として分析できてないけど、なんとなくこの手のコード重複を)なんかあるといいだんけどねえ。
(14:50)
shinh.skr.jp/syard がなんかおかしいという話なんだけど、 まぁ SEGV とかしてて笑った。 これどうしたらいいのかなぁ。
自分が書いたという記憶が全くないものがいくつかあって、 それはまぁ技術的に思い入れがないものが多いわけだけど、 syard もその一つで全く書いた時の記憶がないんだよなぁ。 びびる。 思い出してみると絵をかいてもらったりとか JSに苦労したりとかある気もするんだけど
Scotland yard それ自体はまぁ面白いゲームだとは思う。 あまりバランスとかはよくない気がするけど。
(14:59)
の方はなんというか、要は時間が足りなかった。 体調悪くなる前の一日というか一晩で objdump の結果のパースと、 ptrace でステップ実行するところまで作れたのはよかったのだけど、 本当にそれだけで終わってしまった。
objdump 使う必要はそんなになかった気がするんだけど、 結局 ELF/x86/dwarf と 3つも読む必要のあるバイナリフォーマットあるとだるいんだよな。 まぁ x86 はライブラリにまかせるとしても…
そいや TCC のオプティマイザとか書いてみたいなぁとすこし思う。 x86 を読んで x86 をそのまま吐くようなもの。 スタック使わないようにするだけでそれなりに速くなったりするんじゃないかなぁ。
(16:38)
http://shichiseki.jp/m/?date=20090506#p01
しかし冷静に考えると学生時分に ソフトウェア屋としてですら社会人として働ける自信が無いのに、 ましてよく知らんハードウェア屋とか、 常識で考えてそんな発想しないと思ったのでした。
つまり前の記述はなんかこう、アレですね。 学生を見つけると「学生のうちに〜をやっておけ。俺みたいに後悔することになるぞ」 的なこと言ってるキモい大人系発言だったということですね。 学生の時はどうして社会人と学生の会話はこうキモいのかと ずっと不思議でならなかったけど、 なんのことはない僕もキモい社会人に仲間入りしてしまったのであった!
(18:55)
「学生のうちに免許取っておけ」があるわけだけど、 まぁたしかにあった方が良かったかもね!! とか思うこともあるね。こっちで不便すぎる。
でも常識で考えてアメリカとかに行くとは思ってないわけだ。
(18:57)
というわけでキモいアドバイスの中に一定の真実が 含まれているのは残念ながら事実なんだとは思う。 例えば英語ができなかった僕は 「大人になったら後悔するぞ」とキモアドバイスを受け続けたわけだけど、 まぁ確かに英語できたらいいだろうね!! と今思うわけだ。
だけどかといってキモアドバイスを全部真に受けてりゃ 時間が足りないわけで、
この3つだとギャンブル好きでない人間としては、 どう考えても最後になるよなー
(19:03)
今日やったら207位だった。 成績自体は割といいんだけど、 最後の方の運の悪いっぷりがせつなかった。 経験上ああいう精神状態で無理に悪い手で勝とうとすると死ぬので、 我慢できただけでも良かったと言っていいかなぁ。 手が論外すぎてフロップ見ようともしないから死にもしなかったし。
でも最後オマハのQフラッシュで特攻したらKフラッシュに殺されたのは、 もちょい我慢すべきだったかなぁ…とも。
(19:07)
| 前 | 2025年 9月 |
次 | ||||
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
| 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 | ||||
全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。
_ kik [volatileすげー。コンテスト中はそんな発想は全くなかったからなあ… VHDLみたいだといわれたコードがこんなと..]
_ shinh [そういえばコード生成のスクリプトとかっていただけませんでしょうか。それいじって asm 吐くように頑張れば限界が見れ..]
_ kik [http://as305.dyndns.org/~kik/public/htc-gen.tgz これだと思う。自信な..]