ToDo:
http://d.hatena.ne.jp/nn_x/20120219/1329633519
すいませんすいません…という感じで、東証とかと違って単にわかりきってるバグを放置してるだけのことですな…具体的には長い間ほっといてる ruby ってやつはいずれバカみたいにメモリ使い出してフロントエンドが死ぬってのと、 IO error だかなんだかはよくわからんけど実行サーバ側の ruby スクリプトがよくわからない理由で SEGV してる時があって、起動時のスクリプトで 100 回くらいは retry するようになってるんだけど、 100 回くらいを越えると完全に死ぬとかいう。
個人的には長い間動かしてるプログラムってのは遅かれ早かれいずれ死ぬもんだと思っていて、経験上 C++ でやってると自前でリソース管理してる関係で死亡率が低くなるものの、まぁそうは言っても死ぬ時は死ぬんで、死んでも大丈夫にする方がコスト的にはラクだと思っています。
さくら VPS 以降前は health check して、やばそうならやばい子を自動的に立ち上げなおすとかやってたんだけど、それを以降後動かしてないという怠慢がまず第一に悪いとかなんとか。最近は死ぬ頻度が少ないもんだから手動でもいいかなーとか思っちゃって、しかしやったほうがいいに決まってますね…
言語については Haskell だのあのへんはバグ減らすってことをかなりマジメに考えてると思うんですけど、どっちかというと気持ち悪い/不慣れな/熟れてないシンタクスとセマンティクスと、やはり熟れてない実装でイマイチ使う気起きないとかなんとか…
しかし最近の C ゴルフってやつはなにやら色々すごい感じで全然ついていけてませんな…ゴルフ場カンファレンスというか雑談会が必要な気がする
(21:27)
で個人的には最近は race ってヤツがホットなバグで、チャンネルみたいなやつが解決としては良いなーと思ってるわけですが、チャンネルみたいなやつって深く考えるまでもなく C++ の template で Channel<Foobar*> とか作れる気しかしないんで、誰かがそいうの実装したら案外 race はだいぶ減るんじゃないかな…とかなんとか
(21:30)
10b: 3回前に核心まで行って行ける気がして、2回前に核心が行けなくて、1回前にどうでもいいとこでミスったものの核心が行けて、しかし今回もまたしても核心ですべった。これ通せると 10b 行けたってことで嬉しいんだけど。 10a: へんなとこで違う足場使った。まぁ行けると思うし過去やったことがある気がする… 9: かぶってて少し前はいけなかったやつ。なんかあっさりいけた。実はうまくなってるのかな…とはじめて思った。でも手を打ったのでいたかった 10a: かぶってる 10a にもチャレンジ。無理。 9: 書いてある難易度よりどう考えても難しいものを作る理不尽な人が作ったコース。しかし教育的らしい。手がいたいけどのぼってみる。最後がいける気しなかった
(21:40)
http://risky-safety.org/~zinnia/d/2012/02/#20120227-t0-h1-p0 経由で
http://d.hatena.ne.jp/iasija/20091124/1259060817
を見て、 go の方が遅いってのもへんな話かなーとちょっと動かしてみる。
> erlc ring_bench.erl
> time erl +P 200000 -noshell -eval 'io:format("~w\n", [timer:tc(ring_bench, start, [20000, 100, "hello"])]).' -s init stop
{1435773,ok}
erl +P 200000 -noshell -eval -s init stop 1.72s user 0.21s system 75% cpu 2.554 total
> ~/src/go/bin/6g ring_bench.go && ~/src/go/bin/6l ring_bench.6
> time ./6.out 20000 100 hello
20000 100 1.417406
./6.out 20000 100 hello 1.38s user 0.04s system 99% cpu 1.429 total
1435773 ってのはたぶん micro seconds だろう、と考えるとまぁだいたい互角か、ちょっと erlang の方が遅い。この2年の間に go の処理系がちょっと速くなったって感じなのかな。なんか Core 2 Duo E8400 3GHz vs Core i7-2630QM 2GHz というあたりも考えるとそのへんの違いかもしれないけど。
go のコードは log.Exit がなくなってたので log.Fatal に変えて、 Printf の最後に改行文字欲しかったので入れておいた。
ついでに、 make(chan Msg, 1) は make(chan Msg) の方が速そうかなあというのと、最後の stop は自分に帰ってきてないというのを修正してみたり。高速化はそれなりに効いて、
> time ./6.out 20000 100 hello 2012/03/06 01:51:00 OK 20000 100 1.053176 ./6.out 20000 100 hello 1.02s user 0.04s system 99% cpu 1.067 total
とのこと。
--- ring_bench.go 2012-03-06 01:43:53.020232774 +0900
+++ ring_bench2.go 2012-03-06 01:44:09.200232421 +0900
@@ -16,42 +16,47 @@
func main() {
// コマンドライン引数の処理
flag.Parse();
- if flag.NArg() != 3 { log.Exit("invalid argument.") }
+ if flag.NArg() != 3 { log.Fatal("invalid argument.") }
n , err := strconv.Atoi(flag.Arg(0));
- if err != nil { log.Exit("setconv.Atoi:", err) }
+ if err != nil { log.Fatal("setconv.Atoi:", err) }
m , err := strconv.Atoi(flag.Arg(1));
- if err != nil { log.Exit("setconv.Atoi:", err) }
+ if err != nil { log.Fatal("setconv.Atoi:", err) }
str := flag.Arg(2);
ts := time.Nanoseconds(); // 時間計測開始
start(n, m, str);
te := time.Nanoseconds(); // 時間計測終了
- fmt.Printf("%d %d %f", n, m, float64(te - ts) / 1000000000); // N M 秒
+ fmt.Printf("%d %d %f\n", n, m, float64(te - ts) / 1000000000); // N M 秒
}
// メインの処理
func start(n int, m int, str string) {
- nch := make(chan Msg, 1);
- pch := make(chan Msg, 1);
+ nch := make(chan Msg);
+ pch := make(chan Msg);
// リング作り
makeRing(n, nch, pch);
// リングにメッセージを投げる
- nch <- Msg{command:message, str:str};
+ msg := Msg{command:message, str:str};
for i := 0; i < m; i++ {
- msg := <- pch;
nch <- msg;
+ msg = <- pch;
}
nch <- Msg{command:stop}; // リングを壊す
- <- pch; // リングが壊れるのを待つ
+ msg = <- pch; // リングが壊れるのを待つ
+ if msg.command == stop {
+ log.Println("OK")
+ } else {
+ log.Println("???")
+ }
}
func makeRing(n int, nch chan Msg, pch chan Msg) {
- var prevCh chan Msg = nch;
+ prevCh := nch;
for i := 0; i < n-1; i++ {
- nextCh := make(chan Msg, 1);
+ nextCh := make(chan Msg);
go makeNode(nextCh, prevCh);
prevCh = nextCh;
}
(01:51)
if (foobar) {
LOG(ERROR) << "foobar";
return;
}
if (barbaz)
LOG(ERROR) << "barbaz";
return;
if (hogefuga) {
LOG(ERROR) << "hogefuga";
return;
}
doSomething();
とかやってて、 doSomething 呼ばれねーなでもエラーメッセージも出てないななんでだ…とかしばらく考えてしまった。 Python 使うべきか
(01:41)
ひき続きぼんやりとぷよぷよをやってて、オレオレシミュレータが欲しいな…とか思って適当に書いてた。
JS で書いてて、 linux chrome で試してたんだけど、 android chrome の方の動作が遅すぎるなーとか思って、ちょっと描画まわりをいじってみたりすると速くなった気がする。
でもなんかやっぱり遅い気がする。というか動かしてるうちにだんだんと遅くなっている気がする。描画まわりをいじって速くなった気がしたのは、リロードして速い状態に戻っただけな気がする。 linux chrome では遅くならないのにナゼ…という。 FPS カウンタを入れてみると、やはりみるみるうちに FPS が減っていく
となるとどんどんデカくなってる配列があるとかかな、でも linux chrome では遅くならんしなーと思いつつデータ見てみるも、そんなのはない。そのうちに android chrome の方だと動かす前の画面で放置しててもだんだん遅くなっていくということに気付く。
はてなんでだろう…お行儀の描画 API の使いたしてて、 android chrome の WebKit はそれが秘孔をつくとかかなーとか思いつつ #sdl-fan-jp でフッシギーとか言ってみる。したら firefox と mac chrome でも遅くなっていくと報告していただく。 win chrome は大丈夫。 firefox については自分でも確認できた。
となるとむしろ linux chrome だけがお行儀が悪いことを許してると考えた方が自然かなーと思う。 chrome の挙動の違いも、どっちかというと最近の WebKit だと大丈夫、って感じかなぁとか思う。
しかしやってることは、イベントの取得、 FPS カウンタの更新、キー押されたかチェックしてるだけくらいで終了するロジック、画面消して線一本ひいて4つ画像を表示するだけの描画まわり、くらい。
この中では描画が一番秘孔をつきそうかな…と思う。
画像を表示する部分は
fb.drawImage(images[t+2], x * 16, y * 16);
の一行で、これはさすがに大丈夫だろうと思う。
画面を消す部分は
fb.fillStyle = 'white'; fb.fillRect(0, 0, fbW, fbH);
だけで、これも大丈夫だろうと思う。 'white' とかは実装がすごいバカならすごいことになってもおかしくない気がするけど、 WebKit の実装を思い出すに別にバカだった気がしないし、こんなよく使われてるとこがおかしかったらマズい。一応 clearRect に変えてみたりしたけど関係ない。
線一本は
fb.strokeStyle = 'red'; fb.moveTo(puyo.offsetX + 16, puyo.offsetY + 16 * 2); fb.lineTo(puyo.offsetX + 16 * 7, puyo.offsetY + 16 * 2); fb.stroke();
だけ。これもよく使われてる部分だし秘孔つく気もしないな…と思う。でもそういえば closePath ってあったなーと思って、あれって正方形とか書く時に最後の一辺を書くだけぽいから直線にはいらないと思ってたんだけど…と思いつつ入れてみるもなおらない。ひょっとしたら同じ線を書くオペレーションがどんどん積もっていって、 1000 フレーム後には 1000 回同じ線をひいてるとかになってるのかと思ったのだけど。
はてな…と。しかし linux firefox で再現してるのはありがたくて、 android よりはるかに挙動を観測しやすい。 top 動かしてみると、最初は 10% くらいだった firefox の CPU 使用率が徐々に増えていって、 100% になると FPS が減りはじめる。なるほど firefox で大丈夫な時とダメな時があると思ってた理由は、単に待った時間の差か。あとメモリ使用量は増えてない。まあリソース喰い潰してたらもっと大変なことになるよな…と。
となるとやっぱ描画オペレーションが溜まっていってるのかな…と思って、そういえば canvas の getContext('2d') は最初に呼んで取得したコンテキストをずっと使ってるけど、毎フレーム取得しないと良くなかったりするんだっけ…とか思いつついじってみるもなおらない。まああたり前です。
でもとにかくあやしいのは線だよなーと思って、線をかくコードを消してみる。遅くならない。やはりこれかとなる。これをさっさとやれよ…という感じ。遅くなるって現象が起きるのに時間がかかるから、 iteration に時間がかかるんですよね…
で、ちゃんと canvas の API を読みなおそう…と見てみると、 beginPath というのがある。そうか beginPath で前回の描画オペレーションがクリアされるのか俺はアホかーと。 fb.beginPath() を足して解決。
たぶん最近の WebKit には同じ描画が繰り返されたら省略する、みたいな最適化が足されたのかなぁ、というのが今の予想。おせっかいな感じもするけど、機械が生成した canvas のコードとかで重複が結構あるとかはありそうだから、まぁ悪い話ではないのかもしれないなぁ…
というような、なんだかなぁ…としか思えない、くだらないバグだったんだけど、妙に時間を消費した。思ったこととしては、
最近特に自分で使うものなんて、 WebKit 以外どうでもいいべーとか思ってるけど、セカンドオピニオンというか、まぁ他のブラウザで試してみるのもそれなりにした方がいいかな…ということ。 linux chrome で起きなくて android chrome で起きる問題を修正するのに、 firefox が役に立ったんだから…
ゲームぽいことやる時は FPS カウンタって本当に役に立つよね…ということ。
(02:09)
なんかライブは前のが最後ということで、おーじゃあ今後見れることないのかな…と、うっかり
を買ってしまった。
ミクってのは現象的にはかなり好きで、好きな曲も結構あって、ただ色んな人が作ってるから、あまり好きじゃない曲もいくつかあって、見てる最中の感想は早く終わらんかなだったという。
いや実物見てみたかった…
そういえば会社で「なにごとも最初のやつが一番いいんですよ。VOCALOIDとかもミク以外どうでもいいでしょ」とか言ってる人として MEIKO KAITO かわいそうだなあとか思ったけど、しかしこの DVD にもいなくてかわいそうだった。他のはいたんだけど。
(02:46)
http://logsoku.com/thread/engawa.2ch.net/poverty/1330078980/
2で既に正しい答えが出てるのに、証明できないのをバカにしつつ間違った答えを乱発するという、なんともいえない感じの…
しかし実際このへんの証明とかむずかしいよな…いきなり道端で聞かれたら結構考えそうだ
(16:41)
ことを最近ときどき思う。 たまたま覚えてるってかメモ取ってたのはこの2つ
http://karino2.livejournal.com/86589.html
前者はバランスだいじだよなあとか。
後者はなんか漠然とした感じの質問になんか正しい感じの答えだなぁとか。できづくと natsutan さんだった。
(17:43)
をゴルフ場に足して、これの Quine は結構たいへんだなーと思ったら mame さんが既にやってた…
http://d.hatena.ne.jp/ku-ma-me/20091006/p1
なるほどデータはこいう感じに置けるわけか…
(03:15)
適当にリクエストされてたものとかを足した。 それぞれについて適当になんか書いてみよう
TODO としては、
ちょうどこれだけ足すと 99 言語になるな…
(02:43)
http://wintomorrow.at.webry.info/201202/article_25.html
おもろいな。
なんかイギリスで似たような番組似たなと思った。人気番組という話だったから、フォーマットをマネしたのかも。どんなとこが似てたかっていうと、なんか料理番組ってよりパフォーマンス的なところ。具体的には
とか。
イギリス人はこの番組を見て、料理なんて当然せずにさてととマズい外食を喰いに行くのが日課と、先生が言っていた
(03:37)
僕がよく作る形にちゃんと連鎖尾を入れたい。雪崩と称して適当に4つずつ置いていって同時消しになったり消えないのはそろそろ卒業しないといけない。いきなりむつかしいのはなかなかできないので、形よくなくてもなるだけわかりやすいやつ。
黄色上L
本当は青の下に潜り込ませたい。
http://blog.livedoor.jp/tom109/archives/51101707.html
でも今のレベルで複数潜り込ませると混乱するので、現実的に把握できそうかつ第二折りや潰しに使えそうなのはこういうのかなぁ。
赤の潜り込みさえできれば、残りの赤は割とどこでもいいみたいだ。
黄色Z
この形は左端しかこういう使い方できないんだな…
雪崩の場合は右端限定かな。君案外使いにくい子だったんだね…
潜り込みも手に負えそうなのはこれくらいか…
右端の青を乗せない方が雪崩自体は組めるけどこれはあまりやりたくないな…
黄色四角
黄色が四角になるパターンはこれくらいしか組みやすそうなのを思いつかない。
黄色凸と黄色下L
これはもうわかりやすいから雪崩でいいよ、って気になるけど、高いところは逆さまに置いた方がいい、ってのを忘れがち
(23:22)
http://golf.shinh.org/p.rb?Ladder+corner+problem#dc
dc で対抗してたけど完璧に負けたー。
ぱっと見た感じまぁだいたい思ってた通りループの条件が雑すぎたかなぁ。
しかしそうか kK で整数化できるわけね…これは今まで使ってたテクニックだっけな…
(00:55)
| 前 | 2012年 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 |
全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。
_ Egtra [Channelとは、Go言語とかの類に載っているようなやつですよね？ちょうどそういうものがVisual C++にある..]
_ shinh [あー VC はこいうのがあっていいですね… C++ で実装すると全部 template になっちゃってコンパイル遅そ..]