ToDo:
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)
http://risky-safety.org/~zinnia/d/2012/02/#20120204-t0-h0-p2
なんか気のせいかもですが、日記なりブログなりから他人の日記なりブログに言及みたいなのが減ってる気はしますね。 referrer とかは twitter とかからの方がはるかに多い感じですし。
読む人の量はどうなんでしょうね…
(03:36)
面白い話だな…いいかげんな記憶によると、洛南は総じてちゃんと教えてる面が多かった気がするけど、ムダにアホほど出てる宿題とかは足ひっぱってる感じだと感じたかな…まあそれも長期休暇なにもしないよりはいいのだろうか。ゲームしてる方が有意義な気もするけど…
(15:50)
寝すぎでスタート地点に立つの遅れすぎた。 しかしどうも wonder woman ゲーぽいからな…
kinaba distance を適当に求める
とりあえず RECURRENCE か。 WONDERWOMAN でもいいけど
(17:33)
うーむまけた
http://felicity.iiit.ac.in/tle/ranks
これは完敗だなあ。 100てんぶんくらいの言い訳としては、ねむかったとか、なにやら楽しい夢を見ていたとか、破産の危機が迫っているとかがあるんだけど、200点の言い訳にはならん感じ。
勝てたとしたら wonder woman の提出を遅らせまくるっていう邪悪な戦術があっただろうか。まあそれはそれで釈然としないのでどうでも良い。
kinaba さんおめでとうございます。
(21: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扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。
_ Egtra [Channelとは、Go言語とかの類に載っているようなやつですよね?ちょうどそういうものがVisual C++にある..]
_ shinh [あー VC はこいうのがあっていいですね… C++ で実装すると全部 template になっちゃってコンパイル遅そ..]