ToDo:
なんかライブは前のが最後ということで、おーじゃあ今後見れることないのかな…と、うっかり
を買ってしまった。
ミクってのは現象的にはかなり好きで、好きな曲も結構あって、ただ色んな人が作ってるから、あまり好きじゃない曲もいくつかあって、見てる最中の感想は早く終わらんかなだったという。
いや実物見てみたかった…
そういえば会社で「なにごとも最初のやつが一番いいんですよ。VOCALOIDとかもミク以外どうでもいいでしょ」とか言ってる人として MEIKO KAITO かわいそうだなあとか思ったけど、しかしこの DVD にもいなくてかわいそうだった。他のはいたんだけど。
(02:46)
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)
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)
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)
すごいハイペースで色々行ってる気がするので調べてみた…
旅行充
(01:21)
PHP の足し算のやつは、 PHP 5.3 のいくつかのバージョンでダメで、 PHP 5.2 の一つのバージョンで問題なかったので、元々ダメだったんじゃなくて regression 。
問題の変更はたぶんこれ
こいう挙動変える最適化の前はたくさんテスト書きましょうとか、ちゃんとレビューしましょう、とかが教訓になるのかな。
(01:16)
https://bugs.php.net/bug.php?id=61095
話題になってる。面白いな… これってうまいことやれば SEGV させられるよねたぶん…
(23:21)
何度も似たようなものを書いた気がするものを、 Python 飽きたしイヤなので、 Go を使って書いてみている。少なくともしょうもないけどそれなりに大きいものを書くにはなかなか良い。
まずなんと言っても channel ってやつと coroutine が好き。自明な型とかはあんま書かなくていいのも良い。 Ruby や Python なんかのスクリプト言語に比べるとだいぶ冗長だし、自分で書いたことほとんどないけど、まあ世で見る Scala のコードとかよりもまだちょっと冗長な感はあるけど、 C++ に比べると雲泥。でもなんかダサい感じがあるのは不慣れなせいか、まぁ channel+coroutine 的なライバルであろう、 Erlang に比べればダサくない。
C++ に比べて良いなぁと思うのは、デフォでちゃんと出るバックトレースやら、それなりにそろってる標準ライブラリとかもある気がする。文字列処理やら、正規表現やら。今回使ってるのだと template とかもなかなか強力で良いなぁとか http://golang.org/pkg/template/
実行環境が型とかの情報持ってて、 fmt.Printf("%v", obj) とかでかなり良い出力が出るのも printf デバッグ好きとしてはかなり良いところ。一方でバイナリサイズとかデカくなりそうなんだけど、そのへんはどんなもんなんだろうな。
文句の方は、まず generics の不在はとりあえず痛い気がする。 map[string]int から map[string]interface{} への変換とかそのへんができるとだいぶ良くなる気もするけど、まぁ cast の無い二分木とかが実装できない気がするのが、家で書くコード的にはかなり痛い気がする。なんか家で書くコンパイルしたいコードってしょっちゅう set か priority_queue で探索してるんだよな…あと sort とかもダサい。
Effective Go に書いてあるようなコーディング規約はあまり気にいらない: http://golang.org/doc/effective_go.html
あと慣れなんだろうけど、思ってたより型後置ってやつが違和感がありまくる。それと C++ 脳としてはやはり struct の中にメソッド書きたいな…とか。
パフォーマンス気にしなくていいところで使ってるんで、気にするところだとどうなるかな…てのは気になるところ。
今のところ gdb とかは使ってないから、そのへんがどうなってるかとかも気になる感じかな。
感覚としては、 D よりも僕がぜひ欲しいと思う最重要なところがかなりそろっていて、あまりいらないけどそれなりに欲しいところがかなり無い感じかなぁ。どうも感動的とかまではいかんけどなかなか良いものぽいなと思ってたけど、その予想より少しだけ良いような…っていう感じ。なんていうか思ってたよりハマらなくて、処理系な完成度的によくできてる感が強い。
でも相変わらず家で書くコード的な用途はあんま思いつかないんだよな。 Scala に対するメリットはたぶんコンパイラが速いとかかな…
(23:17)
http://jarp.does.notwork.org/diary/201202c.html#201202211
たぶん ksk さんが変数に _ 使ってるだけなような…
(06:53)
http://blog.practical-scheme.net/shiro?20120213-what-you-want-to-do
内容はその通りだなあというか、特にプログラマに関してはまさにあてはまってるよなぁという感じなんだけど、少し厳しい感じの shiro さんはわりとレアだな…とかどうでもいいことを思った。
そして話は関係ない方向にそれる
日本の大きい会社とかって、プログラム書いたことない人をプログラマとして雇ったりするわけだけど、そういうのっていわゆる、「ウチは10年スパンで雇いますから、最初の能力が中途半端に高いだけの人より、教えたらちゃんと育つ人も採りまっせ」みたいなヤツなんだろうなぁと思う。グーグルは最初からできる人しか採用しなくて、特に人の入れ替わりの激しい分野では良い採用方針だと思うんだけど、普通の大企業のやりかたがすごく悪いか、っていうとそれもよくわからない。
というとこまで書いて放置されてた。
ちょうど一昨日、冗談というか揶揄半分で、大企業だと業務が変わって、最初にやることと変わったりする、みたいな話を聞いて、なるほどそいう面もあるのかなぁとか。
なんか僕が漠然と思ってたのは、なんかどうも面白味に欠ける気がするな…ってことだった。なんか優秀なのはいいんだけど多様性にやや欠けるよなー的な。しかし実際に「プログラム知りませんが、やる気はあります！」ってのが回りにいたら困ると思うから、よくわからない。
(04:40)
| 前 | 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扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。
_ jiro [-Wunreachable-code が -Wall -Wextra に含まれてるといいんですけどねぇ…]