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

はじめてのにき

ここの位置付け

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|06|07|08|09|10|11|12|
2020|01|02|03|04|05|06|07|08|09|10|11|12|
2021|01|02|03|04|05|06|07|08|09|10|11|12|
2022|01|02|03|04|05|06|07|08|09|10|11|12|
2023|01|02|03|04|05|06|07|08|09|10|11|12|
2024|01|02|03|

ToDo:


2009-03-01

_ TCO

酔っ払ってても予戦突破くらいはできるだろうと思っていたけど、 寝てたら無理だとわかった。

マラソンの方は適当に書いたコードで100位くらいだから安全圏だろう。 ほっといてもたぶん大丈夫。

(13:38)

_ メッセージ

1引数関数しかないけど、 1つ引数を取って「1引数取ってなんかする関数」を返す関数を 書ければ2引数関数みたいなもんだよね、 というような考え方があると思う。 未だにわかってないのだけど、ラムダ計算とかいうやつがそれなんだろうか。

でまぁ、1引数しか無いのであれば、 OO ワールドはとても綺麗なんですよ。 なんというか OO のたまに嫌な点の一つとして、

obj.msg(param1, param2)

とかの引数が左右に散ってる印象を与える時があるんだよな。 特に param1 のメンバ関数でもいいよなぁ…というような時。

でも1引数だけでいいのなら その問題は起きなくて素晴らしい。

param2.(param1.(obj.msg))

全く美しくないな…

obj.msg は obj を保持したメッセージを返している、 クロージャ的なメッセージ。 param1.(obj.msg) も同じくクロージャ的なメッセージで、 そのメッセージを param2 に適用して始めてなんか実行されるというような。

まぁなんかだめだめな感じしかしないけど、 OO のメッセージに環境持たせるって考え方はないのかなぁとかたまに思うというはなし。

(14:24)

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

_ nagachika [複数の引数を取る関数を『「1引数取ってなんかする関数」を返す関数』に分解することならカリー化という技法ではないでしょ..]

_ shinh [分解する技法というより計算パラダイムとしてそういう考え方をラムダ計算っていうのかなぁとかそういう疑問でした。 ht..]


2009-03-03

_ んーむ

お話にならない感じだなあ。

とりあえず提出した時よりはよくなっていて 66 倍程度で、 まぁ適当にやれば 70 倍は越えると思う…が、 それじゃ全然お話になってないよなー。

なにかブレイクスルー的なものがあるといいんだけどなあ。 というか大幅に短くなりそうな部分があるんだけど、 ゆっくり考える時間が無いとできなさそうなんだよなー

そもそも今のコードより提出時のコードの方がはるかに良いので、 この程度の中途半端な更新で再提出する気はおきない。 諦めるかなーぎぎぎ。

(00:16)

_ メッセージ+環境

http://d.hatena.ne.jp/nagachika/20090302/oo_vs_lambda

あーうーわかりにくくてすいませんという。

msg[obj][param1][param2] と書いて良いのであれば まぁ Ruby はクロージャあるのでできるのですけど、 obj.msg が msg(obj) の syntax sugar にしか見えない瞬間がある 僕としては、逆にクロージャを OO の記法でやるような考え方/言語はないのかなぁとか思ったのでした。

書いていただいた max も処理まとめるという意味では もちろんそれで良いのですけど、 普通のクロージャになってしまってるので 最後の記法が evens.my_max とかになっていない点で 僕の妄想にはマッチしてないかなぁとかいう。

あと、妄想で「無いのかなぁ」と思っただけなので、 別に素晴らしい考え方だとかは思ってません。 むしろメッセージに環境突っ込むと その後で多態的なのはどこ行くんだとか、 マルチプルディスパッチ的なのはどうなるんだとかそんなこんな。

(21:14)

_ うーん

もにょってたら予定よりあっさり70倍は越えた。 80までは適当にいじってりゃ行くと思う。

なんかちょっと大袈裟に悪い方針だったことに気付いたので直したいんだけど、 えらい手間がかかりそうで困る… でも100倍は見えなくもない位置な気がするなぁコレ…

(22:29)

_ そうそうこういうの

http://twitter.com/kinaba/status/1273532650

(23:32)


2009-03-04

_ うーむむ

80倍は越えた。 えらい手間がかかりそうな変更はそこまで手間ではなかったけど、 軽く100倍行くほど良い変更ではなかった。

適当にやりゃ90はまぁ越えるだろう。 100は、うーんどうかなー

(20:37)


2009-03-06

_ うぐー

今の方針じゃ埋まらんだろうと思ってたのに even pipeline 埋まった…手詰まり感が。

うーむまあこれは投了だろうなあ。 予想よりはよくなったけどなんかもうちょいあったんやないのという感はいなめない。 あと kik さんが余裕釈々すぎて腹が立ちますね。 あと KLab が入賞宣言してるのも腹が立つ。

http://dsas.blog.klab.org/archives/51368711.html

うーむ自信があるのはすごいなあ。

(01:46)


2009-03-07

_ いや

http://twitter.com/kikx/status/1288791976

常識で考えるに kik さんの暴露こそが見たいわけで自分で書いてよ…!

(01:42)

_ TCO Algorithm Qualification Round 3

寝過ごした。

予戦落ちとかウケますね

忘れてた→酔っ払って寝てた→寝過ごした

とか僕の能力を全て出し切った感じである。 その結果が予戦落ちなのだから、まぁ順当な結果なのだと思う。

(01:50)

_ ぼくの村の話

http://www.fukkan.com/fk/VoteDetail?no=3761

復刊されたらしい。 らしいっていうか知らせが来るってことは なんかの拍子でリクエストボタン押したんだろうなぁ。 でも買わないと思うんだな。

読むと成田使いたくなくなるけど、 まぁなかなか使わないのも難しいよねというような。

(01:56)

_ すでに

http://d.hatena.ne.jp/kikx/20090306#1236358887

何言ってるんだという感じだな… いずれにせよ記述ありがとうございます。

(02:43)

_ 100ばい

http://longlong.way-nifty.com/blog/2009/03/hack-the-cell-0.html

そんなに不安定ってなんなんだーという。 単純に少ない数字には倍率が減るって話でもないだろうし…

(10:42)

_ できると言われても

http://d.hatena.ne.jp/kikx/20090306#1236365725

わかんのであった

にんとも…

(10:59)

_ となると

http://longlong.way-nifty.com/blog/2009/03/post-d5ab.html

完敗ですねー。 まぁもともとこいつには勝てんだろ的な人の一人だったので当然な気もします。

まぁいいや。 hack the cell にかこつけて CPU の今後と最適化について僕に教える会を開催したいと思うので、

http://d.hatena.ne.jp/kikx/

http://homepage1.nifty.com/herumi/diary/latest.html

http://longlong.way-nifty.com/

http://www.f13g.com/blog/

http://garakuta.homelinux.org/~nosuke/diary/

http://d.hatena.ne.jp/w_o/

http://d.hatena.ne.jp/methane/

http://tripper.kousaku.in/

あたりの人は東京近辺にいらっしゃったらとりあえずいかがでしょうか。 2ch の人とかよくわからんけどコメント含めて なんらかの手段で通信がいただけたら考える的な。

知らんけど候補日は 3/21 or 3/28 とかそのへんで。

(14:12)

_ herumiさんにも

実質負けてたってことだろうなぁ。 命令数的に勝ってる感じがない。

http://homepage1.nifty.com/herumi/diary/0903.html#7

まぁワンオブ勝てんだろー候補だし略

あと README の文章破綻ぷりというか説明する気ないっぷりには 色々理由があって主にねむかったとか。

とりあえず僕もカウントしてみよう。

even 1269
xor 530
selb 284
cntb 155
sumb 105
shli 32
a 80
ah 50
ai 1
and 27
andbi 5
odd 1270
stqr 147
lqr 583
lnop 27
shufb 68
rotqbyi 128
rotqbii 283
rotqmbii 32
hbrr 1
brnz 1

見て比較した感じ、

  • なんか cntb いらないらしい。
  • lqr の回数はまぁ減らせるよねー
  • って brnz が dual issue になってねーよひどい…
  • あとさっきの反省から andbi はいらんはず

という感じっぽい。 つか post-mortem のために PS3 欲しいというのは…

(14:30)

_ あと

herumi さん shuffle 使ってなくね? 説。 なにかコード見た感じ rotq と sel だけでやっちゃってそうな… そのへんは微妙に勝ってそう、かな?

個人的には shufb は今回一番萌えた命令だったんだけど。

(14:37)

_ TODO

たまっている

  • bfx
  • ada
  • ps
  • lisp
  • TCC いじり
  • grub いじり
  • thread fest のコード読む
  • ゴルフ場の Brainfuck
  • ゴルフ場

(15:10)

_ さいあん

http://www.kmonos.net/wlog/95.html#_1109090307

あまり理解してないけど、 Cyan の方が shibuya.lisp で return がうんぬん… とか発表されてたので質問して、 たぶん kinaba さんが今書いておられるようなものだと理解してたので、 ちょっとやってみた。

globalVar = 0

hello = ^():
  globalVar = return
  return(0)

x = hello()
print x
print globalVar(x+1)
print "\nDONE\n"

うーん 0 とだけ表示されちゃう。 かえせないってことかなぁ。

retret = ^(): return(return)
x = retret()
print x

とすると #<cont 219f5c00> とか出てくる。

retret = ^(): return(return)
x = retret()
print x()

何も出てこない。

retret = ^(): return(return)
x = retret()
print x()()()()()()()()()

何も出てこない。エラーにならないのもよくわからんが…

なんかしら未定義な感じの動作になってそうだなぁという感じで残念?

http://www.geocities.jp/takt0_h/cyan/doc/ref/about-continuation.html

この説明見るとできても良さそうに思えるんだけどな

(16:33)

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

_ kodera [こんにちは。会合面白そうですが、Fixstarsさんの方でも何か 考えられている様なので、ちょっとその様子を見てから..]

_ herumi [ほんとですねー>shuffle 殆ど何も考えてなかったのがばればれ.]

_ 団子厨 [痛い子でサーセンwww 西日本の人間なのでまたの機会にさせていただこうかなと]

_ safii [誘っていただいてありがとうございます. 26日に東京に引っ越すので,28日なら参加できそうです.]


2009-03-10

_ sumb

http://homepage1.nifty.com/herumi/diary/0903.html#9

http://tripper.kousaku.in/20090307.html#p01

思いついてしかるべきだったなあ…と思います。 幸い計数の部分は工夫する余地はあるけどあまり速度に影響しないんですよね… lqr 減らすのがなんだかんだで一番効きそうな気がするけどどうなのかなー

(01:03)

_ けーぞく

http://d.hatena.ne.jp/youz/20090308/1236482522

ぱっとわからない。継続脳が全く育ってないなあ。 後で考える or kinaba 先生の何かをわくてかしてまつ

(02:18)

_ まらそん

一回戦落ち…300位まで通るんだと思ってたんだけど、 250位まで通して後50人はシードってことだったみたいだ。 そうならそうとはっきり書いてよねえ。

http://www.topcoder.com/tc?module=Static&d1=tournaments&d2=tco09&d3=marathon&d4=schedule

こっちにはちゃんと書いてある

http://www.topcoder.com/tc?module=Static&d1=tournaments&d2=tco09&d3=overview&d4=rules&d5=marathon

(10:37)

_ vim.full

http://pc11.2ch.net/test/read.cgi/tech/1173057314/237

よくわからないけど eban さんのご協力のもと できるようになったみたい。

(10:38)


2009-03-11

_ 同じじゃなかったと思うんだ

http://d.hatena.ne.jp/odz/20090310/1236698884

#include <stdio.h>

struct Foo {
    int i;
};

void with_paren() {
    Foo* foo = new Foo;
    foo->i = 42;
    delete foo;
    foo = new Foo;
    printf("with paren: %d\n", foo->i);
}

void without_paren() {
    Foo* foo = new Foo;
    foo->i = 42;
    delete foo;
    foo = new Foo();
    printf("without paren: %d\n", foo->i);
}

int main() {
    with_paren();
    without_paren();
}

手元の GCC では同じ結果になりやがったけど、 cl.exe では、

with paren: 5374216
without paren: 0

とかになった。

↑コメントで指摘いただいたけど with と without が逆。ひどい

(00:43)

_ IA-32 Intel Architecture Software Developer's Manual

紙媒体でゲットした。

反応が以上に悪かったけど、 インテルの英語サイトの方にある連絡先に 本全部の注文番号を送って後は ping しまくれば良かった。 ちゃんと通れば1円も払わずにわざわざ海外から送ってくれる。

嬉しいと言わざるをえない。

(10:43)

_ 露出狂

http://hiraitamado.web.fc2.com/mindex.html

まなぶ以外はどんな感じなのかなあと適当に見てみたらいいの見つけた。 実は新都社すごいんじゃないかな

(22:12)

_ 記憶が確かなら

http://d.hatena.ne.jp/odz/20090311/1236775799

POD型は () をつけるとゼロ初期化だったと思うます。

ゼロじゃなくて各メンバに () つけるとかだったかも知れないけど PODなら実質同じだよね。

あと cl.exe もできたバイナリも wine で動かしてます

dmc.exe とか dmd.exe とか bcc32.exe とかも入ってて、 GCC でクロスコンパイルするとかよりこっちの方がラクなんだよな…

(22:16)

_ new なくても

じゃなかったけと思ったけど これだとなんかな…

#include <stdio.h>

struct S {
    int i;
};

void print_s_without_paren() {
    void* i;
    (&i)[-1] = (void*)42;
    S s;
    printf("%d\n", s.i);
}

void print_s_with_paren() {
    void* i;
    (&i)[-1] = (void*)42;
    S s = S();
    //const S& s = S();
    printf("%d\n", s.i);
}

int main() {
    print_s_without_paren();
    print_s_with_paren();
}

まぁなんかしら GCC でもこっちなら movl $0, -0x10(%rbp) とかがあるかどうかが変わる

(22:28)

_ せるげーむ反省会

http://shinh.skr.jp/h/?HackTheCellPostMortem

懇親会は詳しい検討はむずかしいかも、 とのことなのでまぁやる方向でいいんじゃね、 ということに

勝手に書き換えていただけると幸いです。 あと kik さん kodera さん herumi さんは強制参加です。 ぜひ

(23:41)

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

_ bear.mini [関数名および printf() 内のメッセージの with と without が逆じゃないですか? (with_p..]

_ shinh [うわあ逆ですね。ありがとうございます。 こういう話を嬉々としてするから C++ オタはキモいとさげすまれ、アンチ ..]

_ 団子厨 [セルゲーム反省会の一番最後のLarrabeeってなんすかwwww 参加できないと言いましたが内容次第では新幹線のチケ..]

_ shinh [や、なんか深く考えたわけではないのですけど、やはり Cell と言えば「結局今後あのへんの世界どーなんの?」って話は..]


2009-03-12

_ dmap

http://d.hatena.ne.jp/ku-ma-me/20090312/p1

おもしろい。

def f(x)
  x+1
end

def g(x)
  y=x+1
  y+1
end

p [1].dmap+1
p f([1].dmap)
p g([1].dmap)

g が動くといいんだけどな

(10:07)

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

_ ku-ma-me [それは [1].map(&method(:g)) を改善していくのがよさそうかなあ。 Python だと g だけで..]


2009-03-13

_ がろあ

http://shinh.skr.jp/h/?HackTheCellPostMortem

693 ってガロア組かっ!とか思ったけどスレの 693 さんのことだとわかった。

予想以上にあっさり人数が増えてびっくり嬉しいのですけど、 残念ながらそろそろ人数的に厳しいかもらしいのでした…

なんかなんかちゃんとやらんとかなあと思う一方、 こんだけ面白そうな人いたらほっといても面白いだろうという予想も。


2009-03-14

_ 経緯

http://longlong.way-nifty.com/blog/2009/03/post-4cf4.html

ええまさに懇親会の存在を知ったタイミングでは ああなんか別にやるのは気まずいかと思ったのですが。

  • なんかやろうと思う
  • ふぃくすたーず使っていいよとのこと
  • なんかコンテストの参加人数調べてると懇親会やるとか出てきた
  • そのへんどうなんかね?と聞くにまあそんな気にせんでも良さげ
  • じゃあそれで

とかなんとかでタイミング的には すごい速度で会場提供を持ちかけてくださった woさんに感謝的な

先に懇親会に気付いてたり会場提供無かったらヤメてたと思うし

(14:03)

_ rhgsb

あ今日か… 最近色々見落とすなあ

(14:18)


2009-03-15

_ 陵辱

なんか最近頻尿とか残尿感とかそんな感じだなあとか思ってたけど そろそろなんか明らかにおかしいだろと思ったので病院へ行ってきた。

で、なんかちんこもまれるわケツに指つっこまれるわで大変なのだった。いたかった。 ケツに指つっこむのは前立腺の触診プラス精液回収が目的らしいんだけど、 あんま精液出ないな若いのにとか罵倒されてついでに言葉責めもされた。

老人にケツに指つっこまれて精液出すのが正常だなんてひどい話です。

で、なんか出ないもんだから尿道になんか少し入れられて大変いたかった。 あと運動してるかと聞かれてノーと言うと 運動しないヤツは頭でっかちで中身が無いとか そのうち鬱になるとか言われた。

その時はおもろいオッサンだなーとか思ってたけど、 冷静に考えるとひどい話だった。

でまあ前立腺炎とのこと。 悪いことにはならんけどあんま簡単には治らんとのこと。 ひどい。 運動しろ酒飲むな香辛料喰うなと踏んだりけったりである。

そろそろ自分の体のパーツで健康的な部分が無い気がする。

(22:04)

_ んなことより

TCC の bitfield && long long はそんなに難しいのかなぁ。 どうせやるなら全アーキテクチャで動くやりかたでやった方がいい気がしてきた。

(22:11)


2009-03-16

_ bitfield

typedef struct {
    unsigned long long a: 1;
    unsigned long long ll: 50;
    unsigned int r;
} S;

に対して

   S s;
   s.ll = 0x123456789aULL;

がこうなる。 こう長くなっちゃうと 最適化しないコンパイラの方が読みにくいとおもう

8048459:       48 b8 9a 78 56 34 12    mov    $0x123456789a,%rax
8048460:       00 00 00
8048463:       48 c7 c1 9a 78 56 34    mov    $0x3456789a,%rcx
804846a:       48 89 ca                mov    %rcx,%rdx
804846d:       89 55 ec                mov    %edx,-0x14(%rbp)
8048470:       48 89 c2                mov    %rax,%rdx
8048473:       89 4d e8                mov    %ecx,-0x18(%rbp)
8048476:       8b 4d ec                mov    -0x14(%rbp),%ecx
8048479:       48 89 55 e0             mov    %rdx,-0x20(%rbp)
804847d:       8b 55 e8                mov    -0x18(%rbp),%edx
8048480:       48 8b 4d e0             mov    -0x20(%rbp),%rcx
8048484:       48 89 45 d8             mov    %rax,-0x28(%rbp)
8048488:       48 b8 ff ff 03 00 00    mov    $0x3ffff,%rax
804848f:       00 00 00
8048492:       48 21 c1                and    %rax,%rcx
8048495:       48 89 c8                mov    %rcx,%rax
8048498:       48 c1 e0 01             shl    $0x1,%rax
804849c:       48 8b 4d f0             mov    -0x10(%rbp),%rcx
80484a0:       48 ba 01 00 f8 ff ff    mov    $0xfffffffffff80001,%rdx
80484a7:       ff ff ff
80484aa:       48 21 d1                and    %rdx,%rcx
80484ad:       48 89 c2                mov    %rax,%rdx
80484b0:       48 89 c8                mov    %rcx,%rax
80484b3:       48 09 c2                or     %rax,%rdx
80484b6:       48 89 d0                mov    %rdx,%rax
80484b9:       48 89 45 f0             mov    %rax,-0x10(%rbp)

(00:20)

_ マジメに追わんとわからん

8048459:       48 b8 9a 78 56 34 12    mov    $0x123456789a,%rax
8048460:       00 00 00
8048463:       48 c7 c1 9a 78 56 34    mov    $0x3456789a,%rcx
804846a:       48 89 ca                mov    %rcx,%rdx
804846d:       89 55 ec                mov    %edx,-0x14(%rbp) // 32, 0x3456789a
8048470:       48 89 c2                mov    %rax,%rdx
8048473:       89 4d e8                mov    %ecx,-0x18(%rbp) // 32, 0x3456789a
8048476:       8b 4d ec                mov    -0x14(%rbp),%ecx
8048479:       48 89 55 e0             mov    %rdx,-0x20(%rbp) // 64, 0x123456789a
// uint32 edx = 0x3456789a;
804847d:       8b 55 e8                mov    -0x18(%rbp),%edx
// uint64 rcx = 0x123456789a;
8048480:       48 8b 4d e0             mov    -0x20(%rbp),%rcx
8048484:       48 89 45 d8             mov    %rax,-0x28(%rbp) // 64, 0x123456789a
8048488:       48 b8 ff ff 03 00 00    mov    $0x3ffff,%rax
804848f:       00 00 00
// uint64 rcx = 0x3ffff & 0x123456789a; // 18bit from LSB
8048492:       48 21 c1                and    %rax,%rcx
8048495:       48 89 c8                mov    %rcx,%rax
// uint64 rax = (0x3ffff & 0x123456789a) << 1;
8048498:       48 c1 e0 01             shl    $0x1,%rax
804849c:       48 8b 4d f0             mov    -0x10(%rbp),%rcx
80484a0:       48 ba 01 00 f8 ff ff    mov    $0xfffffffffff80001,%rdx
80484a7:       ff ff ff
80484aa:       48 21 d1                and    %rdx,%rcx
80484ad:       48 89 c2                mov    %rax,%rdx
80484b0:       48 89 c8                mov    %rcx,%rax
80484b3:       48 09 c2                or     %rax,%rdx
80484b6:       48 89 d0                mov    %rdx,%rax
80484b9:       48 89 45 f0             mov    %rax,-0x10(%rbp)

なるほどね。 bitmask が根本的に間違ってるよ。 OK 一見 fix できてる。 つかたぶんこれ x86 でも動くな。

(01:13)

_ いやああ

> cat bitfield_ll2.c
#include <stdio.h>

int main() {
    struct sbf2 {
        long long f1 : 3;
    } st2;
    st2.f1 = 3;
    printf("%lld\n", st2.f1);
}
> gcc bitfield_ll2.c && ./a.out
3
> gcc -m32 bitfield_ll2.c && ./a.out
-18650500345888765

GCC ってこのへんどうなの…

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7018

うーん int より小さいものに long long 使うなってか。

(02:28)

_ とりあえず

なおったことにしよう。

次は transcode.c のマクロか。 なんか思う存分回り道してるな…

他の TODO 忘れすぎだし

(02:49)

_ jaiku

http://code.google.com/p/jaikuengine/

opensource すか。

177348  642108 6749045 total

web service の OSS 化って珍しい気もするな。 OpenPNE とかあるか。

一見だからどうした感は否めないけど、 OpenPNE とかみたいにプラグインとかつくれるんなら なんかコミュニティごとに立てるとかできたりするんかいな。 ちなみに OpenPNE に本当にプラグインがあるかは知りません

(03:04)

_ 24

http://d.hatena.ne.jp/kazuhooku/20090216/1234771983

さすがに 24 はうざいかなあ… とループ書いてみたけど sscanf の方が良い気もした。

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

int main() {
    int i;
    char* buf = "1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24";
    unsigned hits[24];
    char* p;
    for (p = buf, i = 0;; i++) {
        hits[i] = strtol(p, &p, 10);
        if (!*p) break;
        assert(*p == ',');
        p++;
    }
    assert(i == 23);

    for (i = 0; i < 24; i++) {
        assert(i+1 == hits[i]);
    }
}

要は assert がうざいのだけど、 strtok は微妙だし strtok_r も標準じゃないしなぁとかいう。 やっぱ split/join は必要なんだよなぁ。

(10:30)

_ TCC のマクロ

#include <stdio.h>
int A = 1;
#define A 1+A
#define B(x) x
int main() {
    printf("%d\n", B(A));
}

で TCC が 3 とか出力しやがってこまる。 おそらく、 B(A) => B(1+A) => 1+A => 1+1+A の順番で展開されてそうに思える。

でも K&R にある

#define cat(x, y) x ## y
cat(cat(1,2), 3)

とかいう例でちゃんとコンパイルコケるってことは 外からやってるのかなぁ。

(11:18)

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

_ Wcikoeqt [この間も俊太郎の詩をお http://www.stlouisbusinesslist.com/business/5..]


2009-03-17

_ 医者

そういえば

「薬三つ出しとくよ、抗生物質と痛み止めと胃薬」 「胃薬ってなんすか」 「抗生物質飲むんだから胃薬必要なのは当たり前でしょ。胃荒れちゃうから」

とかそんなかんじの会話があって、 今にして思うとこれもひどい気がした。 当たり前じゃないよ

(00:07)

_ split/join

http://b.hatena.ne.jp/entry/http://shinh.skr.jp/m/?date=20090316%23p06

個人的な感覚では、バッファ破壊してようが 一旦ポインタのリストを返しちゃうような実装だと strtol 連打より遅くなっちゃうし、 かといって callback 渡すような実装だとめんどくさいし、 それにたぶん今時のアーキテクチャじゃ分岐予測的な観点で最速じゃない。 まあ関数オブジェクトなり C++0x の lambda を渡す実装ならいいんだろうけど。

でまあというわけで split/join とかしたい時は 99% 速度なんて気にしてないという法則から、 普通に vector<string> かえす split がとりあえず あったりいいんじゃないかなぁとか思うわけです。 まあ insert_iterator を引数とする関数でも許せなくはない。 join は input iterator 二つに対して lexical_cast<string> かまして 合成していくようなのがあればいいんじゃないかな。

なんかしら、C++ の遅くなるようなものは加えれない原則は インターフェースを壊滅的に使いにくくしてると思うんだよなぁ。 他には assert(hogeMap.insert(make_pair("abc", 4)).second); とか書き飽きた。 second とか冗談じゃないというかんじ。

(00:24)

_ あと

C はどっちかというと strtol とか使いつつポインタ進めるような ループを書くことを楽しむ言語ではないかという 妄想があるため、まあそのままでもいいんじゃないかとも

(00:25)

_ 沈黙の艦隊

最近コンビニで復刊してるので地道に買って読んでいる。 足りない分は中古で補完したり別に面白くない部分は飛ばしたりしつつ。 まあ昔読んだことはあるのだけど、地味に面白いなあと思う。 まず「ぼくの考えた理想の社会」ネタは個人的に好きなんだよなぁ。 自分でもよくぼんやり考えるし。

あれこれ考えると自分的には、 「暗黙のうちに個人同士で助けあう仕組みになっていて、戦争がない」 あたりがとりあえずぼくの考えた無敵の理想社会の要素なわけだけど、 後者は目的の同意は簡単に得られるのに方法論がサッパリ見当がつかないんだよね。 そいう意味で破天荒な SF とは言えその方法論が語られるのは面白い。

あとたぶんかわぐちかいじが見開きのとこかなんかに書いていた、 「この本に出てくる人はどの立場の人もみんな自分の仕事に真摯です」 みたいなのがいいなと。 マンガって安易に悪役出しがちだけど、 実際んとこは自分が悪だとはとても思ってない者同士で あらそうケースの方が多いよねー的な

(00:37)

_ まくろ

まとめると、

#define min(a, b) ((a) < (b) ? (a) : (b))
printf("min=%d\n", min(1, min(2, -1)));

は常識で考えて展開してくれないとこまる。

int A = 1;
#define A 1+A
#define B(x) x
printf("%d\n", B(A));

は常識で考えて2回展開されちゃこまる。

さらに、マクロは外から展開していかなければならない。

これらを両立させるには、

  • 外から展開していって
  • 引数を代入する時にマクロ展開を行なう(つまりminの中のminはここで展開)
  • 引数代入の時に使ったマクロは覚えておいて
  • マクロの再帰的な発動と同様、引数代入の時に使ったマクロも発火させない

という感じでやればいいんだと思う。 TCC 的には nested_list をややこしいことにすればたぶん良い。

(22:17)

_ さて

まだややこしいな…

単に nested_list を pop しないだけだと、 第二引数以降に影響出ちゃうか。

(22:29)

_ TCC

C99 に載ってたマクロの例を喰わせてみたら 結果違ったり無限ループしたり色々ひどいなー。 これは大変めんどくさいな。

(22:43)

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

_  [assert の中に副作用のある式を入れたらまずいですよ #define NDEBUG すると消えてしまうので]

_ shinh [全くですね。社内ライブラリの CHECK のつもりでなんか assert にしてしまいました。ご指摘ありがとうござい..]


2009-03-18

_ なんか

型とかぶる感じで出張行くことになりそうな気配があるなあ。 キャンセルして YT さんに黄金なんとかの速さで入ってもらうか

(22:31)


2009-03-20

_ 健康診断

かように明らかに不健康であるものの、 健康診断では特に不健康だとは言われないのであった。 これほんとに役に立つんかなー。

前回は身長172.7体重52.9とかで判定 Cb とかで軽度異常とかだったらしいんだけど、 今回は身長172.6体重51.5とかで平均からの逸脱は激しくなってると思うのに 判定 B とかになっていた。 何が基準だかさっぱりわからんがまぁ 体重とかで異常とかわからんということじゃないかと思う。

まあそんなことよりヘモグロビンが足りないらしい。 件の前立腺には亜鉛が良いらしいんだけど、 要は何かしら鉄っぽいものが足りてないのかなぁ。 たしかになんか会社のメシで内蔵とか出ないしな。

(00:17)

_ zsh on sakura

なんか zsh が動かんくなっていた。 libncurses がどうこうらしい。 とりあえず .cshrc をどければ普通にログインできるようだった。 ちょっとほげった感じ bash があればとりあえず良さげなので exec /usr/local/bin/bash とかでお茶を濁すことに。

(00:28)

_ hack the cell

推定4位(99-100倍の範囲に人がいたら5位)かー。 120倍付近にはいたかった感じだなぁ。 未だによくわかってないけど lqr 多すぎとかが メインの死因だったのかなぁ。 今度調べよう。

110倍台のところにいる人はどなたなんだろうか どいう違いがあったんだろうと気になるな。

学生弱いのは cell challenge のおかげで oxy さんみたいな頭おかしいのがいなかったとかありそうだなぁ。

(06:03)

_ とりあえず

わかってる範囲では

  • 126: kik
  • 120: kodera
  • 11?: ???
  • 9?: nosuke
  • 99: shinh
  • 82: herumi
  • 82: taitai

あたりで、 bit いじった人で 現段階で post mortem にもいらっしゃらなさげな方は 110倍台の人だけかなぁという。

(06:18)

_ bitonic merge sort

def bitonic_sort(a, b, e, z)
  s = (e-b)/2
  return if s == 0
  s.times{|i|
    if a[b+i+s] && ((z != 0) ^ (a[b+i] > a[b+i+s]))
      a[b+i], a[b+i+s] = a[b+i+s], a[b+i]
    end
  }
  bitonic_sort(a, b, b + s, z)
  bitonic_sort(a, b + s, e, z)
end

def bitonic_merge_sort(a)
  s = 1
  n = a.size
  while n > 1
    n /= 2
    s *= 2
    n.times{|i|
      bitonic_sort(a, s*i, s*i+s, i%2)
    }
  end
end

a = [*0...32].sort_by{rand}
p a
bitonic_merge_sort(a)
p a

こんなかんじ? 2 の倍数じゃないと動かんが。

(08:20)

_ putchar

http://q.hatena.ne.jp/1237524919

'\0' が出力されちゃうのはいかがなものかとおもう

(15:34)

_ rob's branch

http://www.mail-archive.com/tinycc-devel@nongnu.org/msg01798.html

http://landley.net/code/tinycc/

でこのバグの fix は rob's mail-list とやらにあるはずなんだけど、 その ML 自体見つからんしこまるね

まあ shared object とかの方が面白そうだしそっち見るか

(16:03)

_ DSO

とりあえず rip 相対以外グッバイすればいいのかな。

(19:44)

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

_ niha [>'\0'が〜 ボクもそう思います…]


2009-03-21

_ うえ

http://twitter.com/pi8027/statuses/1359594979

あまりいい趣味じゃないなぁと思ってしまうので…

(12:35)

_ DSO

とりあえずやらにゃならなさそうなのは、

  • PLT を作る
  • R_X86_64_32 のハンドルがおかしいから GCC の生成したコードから DSO 作れない
  • R_X86_64_32S って何?

あたりか。

(12:51)


2009-03-22

_ わーぷ

普通に 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 なら、

  • 0...624, 4*624...5*624, 8*624...9*624, ...
  • 624...2*624, 5*624...6*624, 9*624...10*624, ...
  • 2*624...3*624, 6*624...7*624, 10*624...11*624, ...
  • 3*624...4*624, 7*624...8*624, 11*624...12*624, ...

と担当すればいいって話か。 ただこれは mt の更新行列がそれなりに複雑になっちゃうだろうから、 log(n) べき乗ができるならそっちの方が良さそうだなぁ。

次元の3乗のオーダーを log(n) 回ってそんなに大きくないんじゃないかな… とか思ったけど、 20000次元**3 を 128 並列でできるので、 62ギガ単位の話。 積和命令とかあった気がするし 62G clock でいけるの? よーわからんけど悪くて 124G clock だろう。 8コア使うって前提の話なので、 15G clock か。 今回の mt_kadai のサンプルくらいだと現実的じゃないけど、 もっと激しく大きければ案外いけるくらい?

眠いので根本的に色々まちがっていそうだ。

(03:00)

_ あと

まあこの手のは基本的にはパズルでしかないので cell 自体の経験はあんま関係ないんじゃないかなぁ。

  • bitslice: 思いつき勝負
  • うまく命令数減らす: kikさんは天才
  • アセンブリ: __asm__ を書いたことがあるか、命令スケジューリングをある程度自動化する程度のプログラムを書けるか
  • spu-gcc とうまくつきあう: 基本的には try-and-error しか無い?

あたりがどっちかというとメインだった気がする。 even-odd の量をうまく散らすとかは重要だけど、 命令数たいして多くないから おおまかに把握するのにそんなに時間はかからないしなあ。 命令をうまく使って命令数減らすのも重要っちゃ重要だけど kik さん以外はたくさん減るのは見つけてない感じだよねたぶん。

一方 x86 とか経験がすごい生きそうだよなぁ。 herumi さんに勝てる気とか全然しない。

と書いてみて x86-64 でこいうコンテストとかも 割と面白いかもなーとか思った。 Core 2 Duo あたりで。 僕自信は勝負になる気がしないが。 誰かやらんかな。

(03:15)

_ こう

分割数が 8 として、 num_rand が 8*10**7 だとして、 800 程度進める行列を普通に(log(n)とか考えずに)作るのは たぶん 640000 回ループ回す程度のコストでできて、

  • 0...100, 800...900, 1600...1700, ...
  • 100...200, 900...1000, ...
  • 200...300, ...
  • ...
  • 700...800, ...

とかいう感じで分割すれば、 通常のループを 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)


2009-03-25

_ なんか

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)

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

_ kodera [ああやっぱり、20人ともなると多少は何かあった方が良いですよね。 簡単にパワポでも用意しときます。すごい部分とか言う..]

_ shinh [ええ、結構時間も長いし、意外と話題も多そうですし、なんか資料的なのはあった方がいいかなぁと。 kik さんには頼んで..]

_ kik [プレゼン形式になってない文書はもうたくさん書いたので 新規で作るのめんどくさいんですが ホワイトボードはありますか?]

_ shinh [あ、はい、あれだけあればあの pdf で十分ではないかと思います。ホワイトボードは…まぁあるんじゃないでしょうかと思..]

_ wo [ホワイトボードはあります]


2009-03-26

_ 微熱

えらいしんどい。スライドとか作れるかなー

(19:11)

_ 16

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)


2009-03-28

_ 出身校

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)


2009-03-29

_ hack the cell post mortem の感想

http://shinh.skr.jp/h/?HackTheCellPostMortem

とりあえず、みんな、 「おおこんなこと思いついて俺 SUGEEE って思った瞬間があったけど、 数日経つとなんだ当たり前じゃんねと思い、 kik さんの説明を見るとああ俺はどうしようもなかったんだな…」 と思うというようなあたりの意識を共有できたかと思う。

まあでも kik さんも時間は湯水のごとく使ってるぽいんだよなぁ。 そのへん次回は彼の2倍程度は時間を使うことで対処したいと思う。

といいつつ、 hack the cell は期間が長いから有給取ってないんだよな。 なんていうか、趣味のプログラムに時間を溶かすことが 完全に習慣になっている人間としては、 3ヶ月から数百時間かそこら捻出することは造作もないことなんだよなぁと。 マラソンとか TLE とか ICFPPC くらい短いとそうもいかんわけだけど。

謎めき系

http://0xcc.net/pub/shibuyapm4/0006.html

について

http://www.f13g.com/?blog

の人に説明したところそれはお前のことだろと指摘されました。 件のプレゼンは現物では見てないけど僕の人生の指針となっていて、 これらの類型にはとてもなりたくない気がするので、 なるべく不明な点が無いように書いてみようと思うのであった。

とりあえず、 ^q-^m とかすると メモモードというかメールを書くモードになるのだけど、 これでまず subject を書くのが問題なんだよなぁ。 subject って途中か最後に書くべきもんだよね本来はたぶん。

いやでもね、

http://shinh.skr.jp/m/?date=20060518#p03

によると大々的に公開することに抵抗があるような 私的なメモであるというような位置付けが書いてあるわけだよね。

実際これを書く前の1年くらいは完全にどこからもリンクはってなかったんだけど、 リファラ経由でぐぐる様が来たりしてヒキコモリ体制が崩れていったんだよなたしか。

まあ僕がちゃんと書くことに関してメリットを感じればちゃんと書くかもですが、 あんま感じなければいい加減に書くのでそのへんは適当に。 気になったことについてのコメントとかはしていただけるとすごい嬉しいです。

ああそいえば今日も思ったんだけど、みんな質問しないよなぁ的な。 俺だけわかってなかったら申し訳ないなーとか思ってしまうので みんな聞いてくれるといいのにとか思うよね。 「何言ってるかわからん」とか質問の体をなしてない僕の質問に 丁寧に答えてくれた kik さんには感謝感謝でした。

あとまあ fixstars のみなさんは色々もう感謝感謝としか言いようがない感じでした。 感謝感謝。

(00:23)

_ so => main

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)


2009-03-31

_ m32 ruby 1.9.0-1

http://shinh.skr.jp/m/?date=20080525#p03

の時の手順でできないな。

extconf.rb 実行した時に bigdecimal でこける。 なんかよく見ると昔は手元の libruby をリンクしようとしてなかったのだけど、 今はしようとしていて、 CFLAGS の -m32 をひきつがないから、 って感じっぽい。

lib/mkmf.rb がどう CFLAGS を扱っているか… なんてことは深追いする体力もないしやめることに。

(01:10)

_ C++

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)

_ PLT

とりあえず現状で 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)

_ C コンパイラツールチェーンから見た x86-64

とかそろそろヨタ話ができそうなくらい どうでもいい知識が溜まってきた気がする。

  • 基本 - あの頃はよかった
    • レジスタいっぱい、無限のメモリ空間
    • さらばx87 / こんにちはSSE
    • long long の実装が自明!
  • code generator
    • 少し不穏な REX プレフィクス
    • あら sizeof(void*) が違うのね
  • ABI地獄
    • 入れ替わる引数
    • あらレジスタどこいったの
    • 可変長引数と向きあう
    • よみがえるx87
  • ELF64
    • RIP相対のありがたさ
    • 広すぎて R_X86_64_PC32 が全然届かない→そうだ PLT を使おう
      • rel => rela
    • 広すぎて R_X86_64_32 がもっと全然届かない→そうだ PIC を吐こう
  • tcc -run
    • 何もかもが届かなすぎる

(23:31)

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

_ intro [PostMortem ありがとうございました!src 置く場所がなかったんで、適当にブログ始めてみましたw&リンク貼..]

_ shinh [おお、わざわざはてな始めてまで感想書いていただいてありがとうございます! こちらこそありがたい話を色々聞けてたのしか..]

_ calgary social media marketing [&#12381;&#12398;&#12424;&#12358;&#12394;&#24847;&#21619;&#..]


2009年
3月
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 10:42) 2.団子厨(2014-05-24 10:42) 3.shinh(2014-05-24 10:42)
search / home / index

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

shinichiro.hamaji _at_ gmail.com / shinichiro.h