はじめてのにき

_ Death of Optimizing Compiler

https://tabesugi.net/memo/2017/8.html

を見て、これ2017年8月の段階かあ、この段階でもまだ、たぶんその通りだなあと思っていた。本当に性能を気にする「ホットスポット」は、 nvidia や intel が、手動や、半手動というか専用ツールみたいなのでカリカリにチューンしてくれて、それで良い気がしていたと思う

今はこう、その「ホットスポット」というのがどんどん広がっていて、 Conv+Relu 速くしたカーネルです！とか LSTM 速くしたカーネルです！ての出してもらっても、 activation 変えたいよう、とか、 attention 入れたい、あるいは変えたいよう、とか言って、ホットスポットは少数の人におまかせー、というわけにもいかんのとちゃうか、という雰囲気になってる気がする

これについて、「djbも読み違えるるもんなんだなー」という印象で思ってたけど、今見ると domain specific tools みたいなのに言及していて、これがどういうものを想定していたかによっては、逆にちゃんと見通していたということかもしれない。というかむしろ現在の状況を語っていたという話な気もする

ところで関係ないけど、なんというか、逆にホットスポットで過剰に速くなってるせいで、研究者の思考が狭まってる気もするんだよな。 GEMM が速すぎて GEMM 使わないという選択肢が無いとか。

(14:00)

_ テュポーン

火力が足りないから確率2回発動に頼らざるを得なくて、2回発動のせいで序盤ダメージ当てすぎで安定しない。第一フェーズはとにかくダメージを入れてはならないので、チェーン待って撃つとかは逆効果、星6も使ってはならない

ややマシな手順

• ウララ: マンダ→ファブラヒール、あとはマンダとアレグロと絶を適当に。2手目のファブラヒールは、第二フェーズへの以降タイミングが不定すぎて回復入れられる保証が無いので、ここで入れとくといいぽい
• セラ: チェーン、あとはブリザガとチェーンもう一回、それだけ
• たまねぎ: 絶、ブリザガ*3、たくす、あと撃てればブリザガ(撃てない)
• トットとビビ: 星5*4、絶、星6

(14:07)

_ nvidia, f*** you

自業自得感しかないが、 cuda 10 入れようとして、ハマった

まず、 Ubuntu 向けのパッケージは、うまく入らない

次に、 Debian 公式のパッケージは、欲しいものではない

よって、 .run ファイルを拾ってきてインストールするのが良さそう

アンインストールは

sudo /usr/local/cuda-9.0/bin/uninstall_cuda_9.0.pl

とかするのが良さそう

うっかり debian の何かを入れてしまった場合、何を消せば良いのかわからなくなる。どうも /usr/lib/nvidia/alternate-install-present というファイルがあると、 .run ファイルが動きたがらないので、これを消す必要があって、

apt-get remove nvidia-installer-cleanup

で消しされる。

sudo service lightdm stop

で X を止めた状態で作業すると良い模様

(01:00)

_ resnet50 10 msec

https://dawn.cs.stanford.edu/benchmark/

たぶん、それほどでもない記録な気がするけど

(23:00)

_ きょうの kati

https://github.com/google/kati/pull/159

なんかヘンなパッチ来てるな、 cisco て書いてあるけど…と思ってたら本当に cisco だったらしい

ヘンというのは、ありていに言ってこれたぶんできがあまり良くない

(23:13)

_ MSDNこそC++

https://qiita.com/administrator1974/items/387aab2a42bf57e3b215

sugoi

(23:33)

_ binary hacks によせて

https://twitter.com/okapies/status/1058272355984728064

当時、「こういう基礎的な話は息が長いですよ」的なことを出版社の方と、あとたぶん主著の人とかあたりが言ってた気がする。当時は「そんなもんかね、まあ僕が書いたようなことはマジで一発ネタみたいな話ばかりだし、というか金に困ってるでいうと今だし、どうでもいいか、いや長期に渡って印税が来るならそれは嬉しい」と思っていた気がする。今でも参照されうる本ということらしくて、当時の出版社の人達の分析は正しかったみたいで、すごいなあ、と思うのと、そんな中長持ちしない一発ネタばっか書いてすいませんでした、という気持ちになる

しかしまあ、普通に考えて、僕以外の人が書いた binary hacks の部分も、だんだんと古くなっていったりもするわけで。いや僕もバイナリぽいやつだと定番の linkers & loaders 読んでフムフムだったクチで、あれのせいで OMF とか未だになんとなく覚えてる感じで。まあなんだろ、「歴史から学びました。 CGI というのはこういう仕組みで動いてたらしいですが、今は…」的な話なんだよな。いやこの喩えも通じないのだろうが……

まあ僕が言いたいこととしては、んな古いものを見てる暇があればこれを読めということで

https://tanakamura.github.io/pllp/docs/

個人的にはこの調子で今ヘッダだけあるような章が全て書かれるのであれば、これは数十年オーダーで生きうるすごい物を書いておられるなあと思っている。いやまあ、長年のなかむらさんの文体ファンとしてはこの文体の文章見られるだけで、あとはどうでもいいレベルなんだけど。例えば、リンカについての文章でこれほど安心感があったことはあまり無いんだよなあ

https://tanakamura.github.io/pllp/docs/linker.html

それはそれとして、ファンといえば、 binary hacks に戻って、正直本自体の内容は今となってはどうでも良いのだけど、 shiro さんが書いて下さった、「本書に寄せて」だけは何度読んでも名文で。

http://0xcc.net/binhacks/sample.pdf

この「表向きの話」の後の文章、これがもう何度読んでも感動的で、今でも自分の行動指針になってるレベルのなんかな気がする。実際実現できてるかはあやしいが。。

(03:42)

_ この前書き

もう本当に好きすぎて何度も読んだのだけど、

本書はその絶好のガイドブックになるだろう

だけは、宣伝していただいてありがたいところなのだろうけど、なんかいらない文章だなと感じるのだった

たぶん shiro さんが最近生まれて幼少期にこの本を見たとして、ガイドブックとか別にこの人いらいないでしょ、という感覚かな

(04:01)

_ あと

ニューラルハックスみたいなのは普通に欲しいな

(04:03)

_ Mesh TF

https://tech.nikkeibp.co.jp/atcl/nxt/column/18/00141/102800030/

直接関係ないけど、 TensorFlow はクラウド屋とエンジニアの発想と持ち物で実装していったところ、設計をことごとく間違えた、みたいな印象を持ってる。まあそのくらい大きな問題にならないくらいの体力があるのがすごいって話だが…

(12:34)

_ 続 affinity

https://github.com/google/kati/pull/156

ほんと、こういうのでパフォーマンスが良くなるのって、 linux kernel の方でなんとかして欲しいという感が

(14:47)

_ 論理が

https://www.trendmicro.com/ja_jp/about/announce/announces-20180912.html

ところどころつながってなくてすごい

仮に「セキュリティソフトを良くするために情報収集が必要である」が真だとしても、許可なく集めて良いことにはならないしなあ

悪意は無い、と書いてある部分は、まあそうなんだろうなぁ、と思うので、つらいなあという感じ

(18:18)

_ 英語むず

https://twitter.com/realDonaldTrump/status/1055719340832686080

yet when I criticize them they go wild and scream, “it’s just not Presidential!”

• them == テロ
• they == フェイクニュース
• 以降主語、発言者はニュース？

(13:20)

_ affinity

https://github.com/google/kati/pull/154

これ発見に苦労して迷惑かけただろうな…ホントすいません系

(13:21)

_ LUT network

http://ryuz.txt-nifty.com/blog/2018/10/binary-deep-neu.html?fbclid=IwAR0wuQ4LTgg02yc7HrML-gNaX-xn_P1EexIH73ZCDXUU8M1eNZu9frvMeW8

いいはなし。これ光学 NN と同じような衝撃がある

(00:37)

_ レビューとビジネスマナー

https://twitter.com/poly_soft/status/1053466632561905664

を見て、

• まあ普通にレビューとかで丁寧な口調で言って損することは無いよねえ
• 間違ってます、って言うより、問いかけによって相手に自分で間違いに気付いてもらう方が上策だし、本当は自分が間違ってた時にも恥ずかしくないし
• 言うて自分も気がついたら妙に攻撃的な言動してる時あるわけだが……

とか思って、しかしツイターの観測範囲では、「プルリクでマナーとかwwwエンジニアはマサカリ投げてなんぼやろwwww」みたいな(ここまでひどい表現はあまり見なかったけど)のも多く目に入るような気がして、うーんとか思ってた

ら

https://twitter.com/nhiroki_/status/1054392924014661632

を見て、なるほどー、そういえば一番最初のツイート自身がビジネスマナーもへったくれもない感じやんけ、と気付く

(23:28)

_ Is this intentional?

丁寧な表現て、基本的にちょっと無駄に長くなりがちで、 "This code is wrong" より "I'm confused :( Could you tell me how this code works?" とかの方がそりゃ丁寧なんだけど、特に英語とかだと面倒で、ぶっきらぼうになっちゃう現象というのが、まああると思う

そういうことを考えていると、 akr さんの提案しておられた、英語バグレポは "Is this intentional?" だけでいい、てのは短いにも関わらず、相手に自分で間違いを認めてもらうスタイルで、すごい完成度高い定型句な気がする

http://www.a-k-r.org/pub/2015-11-08-oedo-rubykaigi-05-akr.pdf

(23:32)

_ なんか

デジャビュ感しかなくて、こういう話定期的に考えてる気がするなと思った

http://shinh.skr.jp/m/?date=20100426#p03

(23:47)

_ proto 批判

http://reasonablypolymorphic.com/blog/protos-are-wrong/

proto はもっとよくできる、と直感的に思う、が、この批判は的を射てる部分もあるけど、外してる部分もあるように思う。 wire format への言及が無いけど、わかった上なのかどうかよくわからない。

現状の問題はこうすれば良いよ、と書いてある点については、要するに普通のプログラミング言語に近付けるということであるけど、シリアライズフォーマットというのは当然プログラミング言語と違うわけで、デシリアライズされた構造体をどこまでリッチにしていっても、結局はホスト言語の機能をフルに使う場合はホスト言語で自分で書いたクラスに移し変えるなり、 proto を持ったクラスにサポート情報を保持して使うことになると思う。そうならないシリアライズフォーマットは、 Smalltalk とかそういう世界観だけな気がする

具体的な例としては、参照みたいなのがまず欲しくなってくるものの一つとしてあって、 YAML とかだと参照があったりするけど、それを足したとしても、今度は、検索が線型より速い構造が欲しいとか、なんだかんだでホスト言語側の機能で自動生成されたコードを補うコードを書くことになると思う

で、どうせ補うコードを書くことになるのであれば、シリアライズフォーマットの仕様はリッチすぎず(ところで最初に批判されてる oneof と map はどちらも後づけ syntax sugar みたいなものだという理解)、便利さと速度やフットプリントのトレードオフがあれば、常に速度&フットプリントの方に倒す、というのは理に適っていると思う。 proto の改善できる部分のうち、どの部分は速度&フットプリントを犠牲にせず使えるかは、ぱっとはわからないなあと思う

API (C++ と Python だけについて書いています) について、 proto は読む方の API はまあ普通で、問題はあると思うがかろうじて苦労なく使えるレベルだと思う。新規にデータを作る時の API も、こっちは多少苦労する程度に気持ち悪い API ではあると思うけど、まあ覚えればなんとかなる。

ただ、 proto の編集は批判されている通り、困った問題が起きることが多い。ただ、それはこう、データを編集しなければならないならちゃんとホスト言語の構造体に移しかえて、編集が終わったらデシリアライズしなさい、というだけのことかなあと思う。めんどくさいよーと思うかもしれないけど、

int LoadInt(FILE* fp) {
  int v;
  size_t r = fread(&v, sizeof(v), 1, fp);
  if (r != 1)
    return -1;
  return v;
}
bool LoadString(FILE* fp, string* s) {
  int len = LoadInt(fp);
  if (len < 0)
    return false;
  s->resize(len);
  size_t r = fread(&(*s)[0], 1, s->size(), fp);
  if (r != s->size())
    return false;
  return true;
}

みたいな関数をいちいち作ってやるのに比べればマシだしねぇ…

なんか、 proto 作った時に、アプリケーション固有の proto と対応した boilerplate コードを作りたい時がある気がしていて、そういうのが作りやすいと良い気がするなぁとか思う。直近での対処は proto とアプリケーション固有コードを両方とも生成することで対処したけど、まあこれで十分という感もある

(18:48)

_ MNIST in Excel

https://www.youtube.com/watch?v=yKt7SI6vexc

既存研究だったか…

(01:37)