はじめてのにき

_ ほげ

てすと

(16:18)

_ 星を継ぐもの

SF 。飛行機とかで読んだ。

最初の方はなにやら楽しげな雰囲気だなあと読んでいた。途中で頑固な生物学者の人いくらなんでもおバカ役すぎないかとか、ちょっと重大事実気付くの遅れすぎだろとか、どうもリアルに感じにくいことがいくつかあったのと、まぁ単純に謎があるー新事実発見ー謎があるーの繰り返しに少し飽きた、というあたりで中盤。

そのへんで SF 者に聞いたところ、ミステリだから最後のオチまで読むとおおーという感じ的ですよと言われて、なるほどミステリならこの展開はアリか、と続きを読む。

後半のあたりで、「えっとひょっとしてオチって比較的自明なやつしか無い気がするんだけど、まさかそれじゃ終わらないよね、ミステリっていうんだから今僕が考えてるのはミスリードされてる方で、その後もう一回くらどんでん返ししてくれるのかなー」と読んでたら、ページ瑞⊂なくなってきてハラハラした。

結局、僕が考えてたオチは第一オチって感じで、もう少し大きいオチが第二オチとしてある感じだった。ミステリだとこう、第一の探偵が言ったことを、第二の探偵が「えっとそれだいたい正しいんだけど、ここの部分正確に言うと…」みたいな感じで、地味だと思うけど、 SF ならまあ良いかなーとか思った。

総じてまあまあ面白かったと思う。

(16:37)

_ test

hoge

(16:19)

_ MessagePack

gmail からおくったらすげー化けた…21世紀にもなって

IETF で websocket の策定にかかわった大先生とやらに話を聞く前に適当な感想を書いておこう。

なんか、僕の感覚では日本勢がなんであのオッサンをひどく嫌ってるかよくわかってない。デファクトとして作ってきたものが標準化されるなんて胸熱展開な気しかしないんだけど。 original author およびその所属の実績とかいう観点では、ほっといて勝手に標準化されたらラクして実績アップて感じな気がするし、ユーザーにとっても標準化されてる技術ってことに損はないと思う。ユーザーに被害が出るとすると致命的に非互換なものが入ってゴミになることだけど、単に実装しきってる方の強みとして「それはうちらとしてはボイコットして実装しないんで、できれば MessagePack と呼ばないで」とか言えば向こうも妥協せざるをえない気がして、なんかとりあえず損はしない気がするんだよな。

すごく運が良ければ良いものが勝手にできて、ほどほどに運が良ければ今あるものがそのまま仕様化される。まあ現実的にはそこまでうまい話はなくて、気にいらないものになりそうだったら拒否権チラつかせて会話する、ってコスト払わないといけなくて、そのコストを心配してるのかなあ。コスト気になるなら単にほっといて気にいらんものできたら無視するよって最初の言っときゃいい気がするしなあ。ぶっちゃけあのスレッド既にそれなりに長いから既にコストといえばコストなんだろうが。

技術的に拙いとかは、まあそのことに深く考えてた人に比べてダメなのはしょうがない気がする、けど深く読んでないのでよくわかってない。ざっと見た感じだと「キミらのナイスなプロダクト、僕に任せてくれれば面倒なとこ引き受けて標準化させるよ〜」的な話にしか見えなくて、むしろ日本の人達がなんでノーから入る感じの身構えムードなのかよくわからん感じ。技術的なとこで「あちゃーこの人ろんがいおじさんだー」というのが判明して、そのせいでコイツに任せてもロクなこと無いって判断してるのかな。

それだと割とスジが通ってそうというか今おことわりムードなのも説明がつく気もするんだけど、最低でもほっといてみてどうなるかぼんやり眺めるとか楽しいと思うんだけどな。まあ僕が楽天的すぎるんだろうか。

(03:14)

_ public => private

https://groups.google.com/a/chromium.org/forum/?fromgroups=#!topic/chromium-dev/CwzjcWd9cYM

地味に controversial な話題だよな…すごい地味だけど…

_ IETF

https://github.com/msgpack/msgpack/issues/121

msgpack を IETF に勝手に提案しようとしてる人がいる、って感じなのかな。 おもしろげ…

(02:07)

_ 風邪

喉がひどすぎて寝れぬー

そろそろアメリカ長め出張なのでこのまま飛行機乗って死ぬ

死ぬ、というか近くの人に死ぬほど迷惑かけそうだ…

(02:16)

_ 間違い探し

https://github.com/sstephenson/ruby-build/issues/290#issuecomment-14013057

xcode 3.2.6 の cc/gcc は gcc-4.2 だったと思うけど、あまし本題には関係ない。

(08:24)

_ OpenGL

• 1.x: 忘れて良い
• 2.0: GLSL 1.1
• 2.1: GLSL 1.2 GLSL ES 1.0 (GL ES 2.0) がここベース?
• 3.0: GLSL 1.3 glBegin 死す
• 3.1: GLSL 1.4 ftransform が消える。
• 3.2: GLSL 1.5 geometry shader
• 3.3: GLSL 3.3 以降 GLSL のバージョンそろう。 GLSL ES 3.0 はここベースだけど geometry shader とか消えてる
• 4.0: tesselation
• 4.1:
• 4.2:
• 4.3:

GL ES 2.0 てのが android, webgl (ただしセキュリティ事情で GL 3.x の機能も使う), nacl などと

(17:29)

_ セキ

上向くと死ぬ。うつぶせで寝るしかない感じぽい。

アメリカ行ってる間にダラス行って MLG っていう大会を見に行ってみようかなぁと思う。 DART とかいう電車があるぽいからなんとかなるんでないか。

そいうので言うとアメリカ行ってる時になんか面白いなんかとかないもんか、と見るとこういうのがあった。 partake の英語版みたいな感じかな…

http://lanyrd.com/places/silicon-valley/

heroku のなんかとかあるなあ

http://lanyrd.com/2013/waza/

(23:14)

_ contrast adjuster

http://shinh.skr.jp/dat_dir/contrast.html#ff0000ff9b9b640000

たまに色の調整とかしたくなるので作ってみた

(16:32)

_ ps4

http://d.hatena.ne.jp/shi3z/20130222/1361511504

いつもはてと思う感じではあるけど、なんかいつも以上感が。とりあえずアドレッシングモードが複雑な点は x86 が不利とか、 JIT うんぬんは確実に謎だとおもう

まあ外野として PS4 のハードがあんま面白くない、ってのは同感するんだけど、現場の人は喜んでそうだな…

(21:57)

_ コントローラ職人

https://plus.google.com/101346259708096774693/posts/DnrwWdi7B9q

やったー

(01:04)

_ optimust

TLE の後継、らしい

http://felicity.iiit.ac.in/web2py/Portal/default/event_home?event_id=6&tab_id=1

ぼくは比較的クソ運営には優しい方だと思うんだけど、5時間のコンテストでデカい問題修正入ったり、細かい条件全然書いてなかったり、全てのページ見るのに1分かかったりエラー出たり、はきつかった。

ant

とりあえずシミュレータ書く。で、解答出ない。なかなか答え出ないなー。問題の入力を見る。これ答え本当にあるの…? だいたいあるとしたらこれ、 input 0byte だから、解答自体は無茶苦茶短いんじゃね…でも解いてる人いるなー…と考えて諦める。後になって rejudge で正答者ゼロに。

permutation

permutation って地味に書けるかっていうと毎度悩むよね…と、例のごとく悩みつつ、まあ解答を提出。解答を permutation にするのは楽しそうだから後でやろうと。

lcm

簡単だなーサクリ。 WA 。はて…色々いじってみるも WA 。てかこんな簡単な問題誰も解いてないのヘンじゃね…と思いつつ次に。後で問題文が強烈に難しく変更されて、正答者ゼロ。

textart

こういう問題やり飽きたんだよな…と飛ばす。

ticket

うーんと考えてから書く。 WA 。あるえーと考えるもわからん。ていうかこの問題、僕の問題の理解が正しければ N^2 組み合わせができるので、 N で割っても無限に点数増えると思うんだけど…

stringint

これは簡単かなーと適当に書く。 SEGV 。 SEGV ってメモリ制限かなーとかいじるも SEGV 。ひょっとして return 0 ですかーと修正したら WA 。問題をリロードしたら解答は long long におさまらんよ、とのこと。デカい整数 C で扱うのめんどい、次。

次ってもう終わってるなーということで permutation の解答を permutation にして満足しようということに。適当にやっても全然点数増えない、ていうかコードサイズ自体はかなり増えてるのに、点数がほんとど変わらない。おっかしいなーと色々やるがよくわからない。最後の方にアルファベットだけかーと気付く。全部使った方が面白い問題だと思うんだけど…と思いつつ、そこだけ修正してここだけトップに。ていうか submission のとこに出す点数はその submission に対する点数にしてよね…

permutation の解答だけ。 strlen は明らかに消せるので l が落ちて 16 にはなる。 qsort も sort 書けば消せるので q が落ちて 15 にはなったと思う。

http://shinh.skr.jp/t/perm_cmp.c

(05:29)

_ quick sort

http://togetter.com/li/445854

的な話を見ると、いつもこのスライドを思い出して心が痛むので言い訳しておいてやった…

http://shinh.skr.jp/slide/mederu/012.html

(11:58)

_ diablo 3 1.0.7

一応 PvP ができるようになったというのがウリ…なんだと思う。 pub で少しやってみたけど面白くない。知った人とやるとまだマシかもしれないけど一瞬で飽きそう…

クラフトもいいものそんなにできるとは思えない感じで微妙…

(06:30)

_ -fvtable-verify=std

http://gcc.gnu.org/ml/gcc-patches/2012-11/txt00001.txt

が

http://scarybeastsecurity.blogspot.jp/2013/02/exploiting-64-bit-linux-like-boss.html

への対処ってこと…だと思う。

(13:55)

_ SC2 女性対決

http://www.gomtv.net/2013gstls1/vod/71957

gomtv 初の hots (beta test 中の SC2 の新パッチ) が gomtv 史上初の女性プレイヤー登場かつ女性対決という、まぁそういう申し合わせがあったんだろうけど、心暖まる展開だった。

ただ試合の内容はひどい…マスターどころかダイヤレベルあるんだろうかってぱっと見の試合だった…

女性プレイヤーだと外国人 (韓国人でないという意味) の scarlett ってのは本当に強いらしく、普通に外国人一線級韓国では二流くらいの人達に勝ってる感じ。

(23:20)

_ PTT

http://ptt.prosym.jp/arc/388/

タイトルに魅かれてひさびさに行ったら、すごい楽しかった! はじめて HTM 含む TM に価値があると思える話だった。未だに STM は信じてないけど、後の呑み会で STM が速くなりうるケースはあるよんと教えてもらって、なるほどなぁとかそういう。

ちょうどよくわかってなくて、なんとなく知りたいなーと思ってたあたりをわかりやすく、かつ詳しくはないけどなんとなく言葉は知ってる ruby の文脈で語ってくれたので、僕にとってわかりやすめでラッキーだったというのもあるとは思うけど、すごく良い話だったと思う。後でリクエストしようと思ってたけど忘れてたんだけど、発表資料どっかに上がるといいなー。

遅れて行って、最初の頃は発表より GSL っていう SC2 の大会の今日の動向の方が気になってたけど、後の方は GSL どうでもよくなっている程度には面白かった。聞いてる最中に色々疑問が出てきて、これは後の方で語られるかもな…と思いつつ質問リストをメモしつつ聞いてると、ほとんどの疑問がすぐ後で明解に語られる感じで、なにやら突っ込まれ慣れてそうな人の話ってのはいいなーとか思った。いくつか質問として聞いたこともあったけど、わりと些細なことばかり。そしてその僕の疑問に対する解答は、僕が明示的に聞いたものに対しても勝手に解答されたことに対しても、僕の期待以上によく考えられてる感じで明解に答えられて、感心な感じだった。

やーすごい人はそこらじゅうにいるもんだなぁとひさびさに思いました…

メモをとりあえずダンプ

• ハードウェアで TM やる時は eager HTM と lazy HTM てのがあってどっちがいいかってのは論争あるけど、とりあえず eager が実装ラクらしい (あんまよくわかってない)
• TM 中に競合があった時の retry 時に待ち時間は入れてるのかなーと思ったのだけど、 ruby のケースではあんま関係なかったらしい
• 件のメインフレーム CPU にはランダム時間待つ命令があるらしい
• TM に入る時の粒度は動的に調整するとよかったりなのかなーとか思いながら聞いてたら動的にやったらしい
• 動的にやるとそれが落ちつくまでロック取らないといけなくない? と質問したところ 1. 最初の 300 回くらいの結果で良しとするのでたいして問題ない 2.かつ実際のところ多少不正確でもいいのでロック取ってない、との解答
• inline method cache は無効化したとのこと。それも TLS に置いたら良くないの? て聞いたらめんどくさかったとのこと。あーそうかアレって命令列にひもづいてる感じだっけみたいな。ていうか inline ってそういう意味の inline なんかな
• cahce line が 256B とかあって false sharing 起きるから TLS ぽいものは 256B にアラインした
• だいたいメモリ管理、具体的には rb_newobj と gc_lazy_sweep で競合起きてた
• pthread_getspecific ってクソ遅いから __thread 使えないの? ってのはコンパイラツールチェインが対応してないとのこと。 pthread_getspecific で取ったポインタを後生大事に使いまわしたらいいんじゃ、って質問にはなるべく使いまわすようにはしてるとのこと。
• haswell でどうなんよ、と思ってたらあっちは件のメインフレーム CPU よりデバッグ情報少ないから大変そうだけどパラメータいじったら動くんじゃね的な
• 100 コアあったらどうよ、という質問に対しては 8 thread で既にグラフが寝始めてるからどうだろ、と。ただベンチマークに使ってるケースがイマイチバカ並列じゃないから、そのへんの特性もあるとのこと
• 競合起きた位置わかんるのかなーてかどうやってチューニングしたんだろ、と思ってたら、読み書き集合がぶつかった時の命令のアドレスと、ぶつかった物理アドレスはわかるとのこと。それじゃあ色々キツいわけだけど、 haswell だともっとキツいからキツそう的な。

あと呑み会でコンパイラの人の話を聞いてて覚えた略語

• PRE: partial redundancy elimination
• GVN: global value numbering

(02:41)