ToDo:
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)
なんで駒場に行かにゃならんの… ということで雨もふるし大変うざい選挙になってしまった。 どうも期日前投票するべきだったみたいだ。
好きでない共産党にわざわざ投票しに行ったのに 落選してしまったのでかなしかった。 タリーズめ…
しょうがないのでついでになんかしようとマンガを 読んだり買ったり。
読んだ:
ドリフターズは普通に面白そうだなーと思った。 ローマとカルタゴの人を知らんかったのでちょっと歴史の勉強した。
眠れる惑星。 あいかわらずストレートに都合のいいエロマンガかく人だなぁとか思った。
打撃天使ルリ。 3巻で終わってたのかー。 1巻あったら買ったんだけどな。
殺しや1の人とのぞき屋は同じ作者だったようだった。
罪と罰はなんか時代ずらしただけじゃなくて、 ソーニャの立ち位置とか全然違うっぽい。 なんかラスコーリニコフ役から信念が感じられないのがいけてないなぁとおもった
カイジ。つまり福本先生この話実体験ってことすか…的な
あと忘れたけどもろもろ。 燃えよペンってもっとぶっとんでた気がしたんだけど、 今見るとなんかそうでもない気がしてしまった。
買った:
地雷震1。最初の方はどうしようもなく救われなくていいよね。 そういえばウシジマ君もなんか少しいい人になってて そのへん地雷震ぽい気がちょっとした。
ジャぱん18 はですよがついてる話を読んでおこうかなぁとか思って買った
初期のURASAWA 。激しく読んだことあった。
劇画自民党総裁。勉強になった。
まるごと西原理恵子。 西原理恵子のマンガの読み方としては これはすごくいい売り方な気がするなぁ。
恐怖新聞。 うしろの百太郎の方が事実として押しつけてくる感が強い感じなのかな。
そんなことよりやりたかったことはあるはずなんだけど無駄な日曜になった
(23:53)
http://shinh.skr.jp/dat_dir/mederu/041.html
ここで「たぶんできそうげ」と書いた、 アルファベットだけの Perl で任意コード実行だけど、 今考えると比較的簡単にできるのであった。
同じく quine も書けると思う
今度なんか書く
(02:35)
あの英語は失笑を招くほどひどいらしい。
みんな英語うまくていいなぁとしか思えない。
や、日本ぽい発音てのはそだけど、 どう考えても通じると思われるので別にいいじゃんね…
あれがダメだっていう人はこう、 インド英語とかもダメってことになると思うんだよな。
なんか楽天に関しては色々思うことが混じっていると思う。
最後の意味でこいう意見はとてもこわい。
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://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/yshl/20100704#1278255925
おおありがたや、ということで適当に
http://github.com/shinh/w3m/commits/master
(00:45)
そうか $ をいじるという手があったかー
僕は 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)
っていうジャンルがあるんだなぁ。 よく考えるとメインなノート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)
http://d.hatena.ne.jp/nurse/20100702#1278054508
CGI 好きなんだけどなぁ。
Process isolation というのは本当にいいもので、 つまりこう Ruby がクラッシュしようが メモリバカ喰いしようが、 そのプロセスさえ死んでくれればいいわけで、ねえ。
ゴルフ場はなんとなく FastCGI だけど、 正直 CGI の方がいいんちゃうかなーとかたまに思う。 なんかたまにメモリ大量消費してて、 よくわからん。
しかしまぁ、僕とかは ruby で web のなんか作る人間としては、 それこそ CGI.rb にそれなりに我慢ができる程度に 圧倒的にライトユーザなので、 まぁ意見としてはどうでもいい層なんだと思う
(23:56)
割と面白いかなぁ。 保存しないと反映されないんだけど、 html なんだからもうリアルタイムで更新してくれてもいい気もするな。 JS とかは保存を待って欲しいかもしれんが。
縦書きを transform でやってるのがあったので、 適当に flexbox でもやってみた。
Firefox だとびろーんと長くなった、が気にしない方向で。
(00:37)
つまり僕の転職候補会社が一つなくなったということだけど、 元々その可能性はとても低そうなので別に関係なかった
いや、しかし、これで楽天が大成功しちゃったりすると、 他の企業もマネしたりして、 つまり僕の転職候補会社が減っていく、 そういうことになると大変悲しいのだけど、 元々その可能性はとても低そうなので別に関係なかった
(23:23)
| 前 | 2024年 10月 |
次 | ||||
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
| 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扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。
_ naruse [正規表現ライブラリ、TREってのもありますね。http://laurikari.net/tre/]
_ shinh [おお、ぱっと見良さそうですね。速ければ、ですが。ありがとうございます。]