はじめてのにき

_ ラーメンやさん

なんかまだ人が入りはじめる前くらいの時間に行って、席がガラガラなのに外で並べと言われて、不愉快に思った。待つのはいいけど座って待たせてよって。なんかサービスが悪いとかってほとんど気にならない方だと思うんだけどな

考えるに、わざと行列作って客寄せにしろって方針なのか、なんかそれとも単にオペレーションが腐ってたっていう、ハンロンの剃刀的な話なのか。実際忙しそうではあったし

(01:22)

_ あたたかいはてぶ

だ

http://b.hatena.ne.jp/entry/s/amachang.hatenablog.com/entry/we_joined_smartnews

と思って下の方を見ていくとチラホラと機嫌の悪そうな人たちが

(21:34)

_ NVMe

とかいうものがあるということを教えてもらう。PCにいつのまにか知らない端子が増えてるということに衝撃を受ける

$ sudo hdparm -Tt --direct  /dev/nvme0n1
/dev/nvme0n1:
 Timing O_DIRECT cached reads:   3362 MB in  2.00 seconds = 1683.70 MB/sec
 Timing O_DIRECT disk reads: 5092 MB in  3.00 seconds = 1697.20 MB/sec

速いなー。HDDとSATAのSSDも

$ sudo hdparm -Tt --direct /dev/sda
/dev/sda:
 Timing O_DIRECT cached reads:   948 MB in  2.00 seconds = 473.37 MB/sec
 Timing O_DIRECT disk reads: 634 MB in  3.01 seconds = 210.69 MB/sec
$ sudo hdparm -Tt --direct /dev/sdb
/dev/sdb:
 Timing O_DIRECT cached reads:   910 MB in  2.00 seconds = 454.93 MB/sec
 Timing O_DIRECT disk reads: 1366 MB in  3.00 seconds = 455.12 MB/sec

(01:24)

_ 機械学習、温故知新

https://turingcomplete.fm/14

でshiroさんが、「昔やったことが意外なところで役に立つことがある」的なことを言っていて

http://rebuild.fm/206/

でも森田さんが、「今現世的な益がなさそうに見えても面白いと思ったことをやっておくと、後でその仕事が必要になって飛び込むことができるかもしれない」というようなことを言っていた。

これは本当に良い話(rebuild聞いてて気付いたけど、僕も「良い話」という言葉を時々使うのは完全に森田さんの影響だな)で、昨今の深層学習は温故知新的な話が多いなあと思う。大きいところでは

• ニューラルネットが深くなっても学習可能になって、不死鳥のように蘇えった
• Uberが「GAも生き返る！」とか発表したりしたり https://eng.uber.com/deep-neuroevolution/
• 計算リソースがアホみたいに必要だけど(現段階では)単純な処理しか必要ないため、GPUですら機能多すぎでオーバーキルで専用アクセラレータ作るってのが普通になった
• systolic arrayとか死語だったらしい
• プログラム言語もどういうのが適切かーみたいな話をみんな考えてて、突然swiftがあらわれたりと
• 型システムも再考されるべきだと思う。中途半端な依存型みたいなのがたぶん欲しい

などなど

(10:36)

_ 小泉

https://mainichi.jp/articles/20180502/ddm/004/070/014000c

正直で面白いなー

−−原発の危険性は長く指摘されていましたが、耳には入らなかったのですか。
反原発は左翼勢力がやっていることくらいにしか思っていなかったから。

とか

私は原子力技術を知らないんだから霞が関を信用するしかないだろう。
（放射線量の単位の）シーベルトなんて言葉も知らなかった。
すべて専門家が把握していると思っていたし、彼らに聞けば、 
皆が「安全だ」と言っていた。
福島の事故が起きて「だまされていた」と気付いた。

(16:38)

_ 戦場飯

おもしろい

https://www.hotpepper.jp/mesitsu/entry/yasushi-nishimuta/18-00065

「自分たちが良しとする価値観は、万国でも良しとされるに違いない」という、
一種の傲慢（ごうまん）さでしょうか。

とか……

(21:51)

_ TPU vs GPU

https://blog.riseml.com/comparing-google-tpuv2-against-nvidia-v100-on-resnet-50-c2bbb6a51e5e

ふむふむ v100 と比べてもパフォーマンスいい勝負できてるんだなあ(個人的な体感と一致する)、それならコスパはよかろう……と思いながら読んでたら、 accuracy が違うとか出てきてひでえと思った。TPU側がむしろ損する違いだと説明されてるけど、まあ同じモデルで比較してよねぇ……

(00:46)

_ まつもとひろゆき

http://programming-study.com/trouble/programming-language-learn/

なんか10年くらい前のダメ記事定石みたいな古典テクを久々に見た気がする

(12:53)

_ 民度

https://twitter.com/page_eco/status/986246602376425472

アジア民度ひくい

(22:08)

_ kawango

http://kawango.hatenablog.com/entry/2018/04/04/143826

好きな発言をいつもしてる人だからといって全てに同意できるというわけではない、ていう好例だなあ

(01:49)

_ アホの子教える

https://anond.hatelabo.jp/20180317085745

via https://twitter.com/miura1729/status/974852239398289408

いい話だなーと思うけど、自分でやるのは難しそうというか、できる気がしないなぁ。中学校くらいの時に教師という職に一瞬憧れたことがあったけど、なんか俺教えるの壊滅的にヘタじゃね、てすぐに気がついた

(18:46)

_ 抽象化レイヤを重ねる

tcfm聞いてて、beflispの時はLLVM bitcodeからbefungeへの変換を書いてあまりうまくいかなくて

https://github.com/shinh/beflisp/blob/master/bc2bef.cc

8cc=>ELVMの後でLLVM=>ELVMのLLVMバックエンドを書いたので、ふたつの話が混じってるんかなと思った

https://github.com/shinh/llvm/tree/elvm/lib/Target/ELVM

さて、等価な変換でレイヤを重ねてくと、2枚くらい重なったあたりから、1レイヤずつでしか検証してないにも関わらず、2レイヤ一気に重ねても思った通りに動いたりして嬉しい、みたいなことがあると思う。コードのコンパイラなんてのは割とそんな感じで、C言語とマシン語なんて結構抽象度が離れてるのに、なんか動いたりして感動するっていう

ELVMの時のことを考えると、僕が思うに抽象度は

C++ > C > 8cc > マシン語 > ELVM > BF

みたいなイメージだった。抽象度が離れてるところをいきなり直結するのは大変なので、さらにレイヤを重ねたり、既存のプロジェクトにうまく乗っかると割とうまくいく。

そんなわけで最初は8ccに乗っかってセルフホストまでは楽ができた。でもその後、8ccは残念ながらCのフルセットが正しく実装されてるとはいえない感じだったので、もっと色々動かしたいとなると問題が出てきた。

というわけで、やっぱりC言語の処理系としてはだいぶまともな、tinyccあたりからELVMに落とすのが正解だったかな、と思ったけど、しかしどうせならC++とかも動くと楽しいよね、ってことでLLVM=>ELVMをやってみたのだった。

これはまあ、できたと言っていい状態にはなって、一応C/C++のコードを普通にELVMひいてはBFとかで動かせたりするようになった。でももっと色々なプログラムを動かすとなると、8ccの時からあったもうひとつの問題が出てきた。ELVMのヘンな制約、sizeof(char)=sizeof(int)=1みたいなものを考えに入れて既存のコードが書かれてないので、なんかそのままコンパイルしてもあんま動かないじゃん、てなった。

こういう抽象化の漏れってのはレイヤ重ねる時は結構致命的で、C/C++のレイヤなのにsizeof(int32_t)==1とかになってると、まあありとあらゆる問題が出てくる。実際、LLVMより上のレイヤであるところの、clangの方にELVM用のアドホックな変更がいくつか必要になったあたり、この漏れがわかりやすく出てた感じだったかなあと思う

https://github.com/shinh/clang/commits/elvm

もちろん抽象化が漏れてるヘンな環境はそのままにしておいて、移植するソフトウェアをヘンな環境に適合させるのもそれなりに楽しくはあるけど、まあ結構大変。これはなんか方針をミスったかなぁと思っている。実際最初のELVMで8ccを動かした時とかは8cc側への変更が結構大きかった。その後でELVM側に__builtin_xorとかを足す感じで、8ccへの変更を減らしていったりした。下っかわの変アーキテクチャぷりが強すぎると上がすごく不安定になる、ってのはまぁNaClとかもそんな感じだった。まあアレは上に巨大なもの乗せようとしてたってのがあるが

やりなおすとすると、やっぱりレジスタとかは32bit/16bit/8bitの3種類くらいの幅があるべきだったと思う。サポートできないバックエンドではエミュレーションを用意すれば良いだけだし、肝心の(?)BFはサポートできるし。ていうかなによりLLVMへの変更がたぶんすごく小さくなるってのが良いように思う

でも、思い出してみると、maloaderとかもlibcレイヤなんていう抽象化漏れまくるレイヤで切ってるのでガタガタだし(特にFILE構造体が悲劇的)、NaClもずいぶんと不安定な土台だった。なんか不安定だけどバランス取れてるもの作ったり、その不安定なものの上になんか乗せるのが僕は好きなんだろうな……トランプタワー的な

(01:27)