はじめてのにき(2018-06-19)

2018-06-19

_ 転職話

グーグルを悪く書かない
他に受けた他社を良く書く

のふたつはゴールだったんだけど

http://shinh.hatenablog.com/entry/2018/06/17/203604

へのブクマとかtwitterとか眺めてると、グーグル < PFN みたいなのが結構あるし、他社については語られないし、なかなか難しい。他社も本当にすごい良さそうだったんだけど、具体的には書かないべきだろうしなぁ。あ、逆に僕が面接受けに行った会社の人はそのへんの情報は自由に共有してもらっていいです。

グーグルへのもう一つのどうしようもない不満というと、どうしても大企業なので one of them になっちゃう、というのがあったけど書いてなかった。あの会社で one of them にならない方法は Jeff Dean になるしかなく、無理ゲー。まあ完全に大企業の安定感とのトレードオフだし、僕は安定指向なのでそっちの方がいいや、て思ってたけど、逆の方もやってみたいな……と隣の芝に行ってみたというような。

その例をとってもそうだけど、当たり前だけど会社間に全順序つかないなぁ、というようなことは何度も思った。

人によってあうあわない、タイミングによってあうあわないあるわけで、グーグルでプロジェクト変える程度に気楽に、小さい会社も含めてジョブホップできるといいなぁ、と思う。そうなるとグーグルジャパンも焦って給料増やすかもしれないし。今までは基本的にグーグルが取っちゃうから他が給料上げてた構図があったと思う。シリコンバレーとかなんかそういう感じで回ってるよね。

11年も一つの会社に行っておいてなんだけど、まあみんなもっと動(く|ける)と良さそうだよね

(15:35)

_ cQASM

https://arxiv.org/abs/1805.09607v1

を斜め読みした。学生の時に鉄板教科書と言われてた Nielsen & Chuang が QASM の導入者、とか見て、おおーと思った。ていうかこれ系のアセンブリ言語みたいなのは、当時も見た気がするから、その当時見たのが Nielsen & Chuang のやつなのかもしれない。

ぱっと見の感想としては、こういうのは時期尚早、各人が適当に「俺のを標準にしようぜ」ってなるんじゃないかなぁ……という感じ。実際、 IBM Q の人たちぽい

https://arxiv.org/abs/1707.03429

の OpenQASM を斜め読みした感じだと、それ以前から cQASM ぽいところ考えてるぽいし、 cQASM の論文で OpenQASM が引用されてるしで、はてさて。

あとコンパイラも乱立しててすごいね。

(15:50)

_ zapcc

https://github.com/yrnkrn/zapcc

goma のライバルだ。この分野(バカパラレルじゃない並列/インクリメンタルビルド)は昔調べた時は死屍累々で

https://gcc.gnu.org/wiki/IncrementalCompiler

ftp://gcc.gnu.org/pub/gcc/summit/2003/GCC%20Compile%20Server.pdf

など

(16:00)

_ おもしろ

https://twitter.com/chinshonatsuyo/status/1008057976911876097

ブームが終わって、採算があって常識的に便利なものは残りつつも、単にブームで湧いただけのものが消えていってる、て話か。そりゃ当然そういうことは起きるよなあ。逆に言うと今後も今くらいの順当な強さをキープするのかね。

あとリプライがそれ以上に(悪い意味で)面白かった

(16:17)

_ ScaffCC

https://github.com/epiqc/ScaffCC

clang が魔改造されてて、 C ぽい文法だけどいじくられてる何かを LLVM IR に変換する。ターゲットは x86-64(!) で深く気にしない
opt に pass が色々足されてて、最適化しつつ量子情報向けの色々をやってる。ぱっと見てわかるのは scaffold の module というのが関数に対応してるぽいけど、それをインライン化してる https://github.com/epiqc/ScaffCC/blob/master/llvm/lib/Transforms/Scaffold/InlineModule.cpp
LLVMバックエンドは完全無視(!)で opt の pass で標準エラー(なんで err() に出力してるねん!)に吐いて出力としている。たぶんレジスタアロケーションとかは完全にいらないのであろう。例えば https://github.com/epiqc/ScaffCC/blob/master/llvm/lib/Transforms/Scaffold/GenQASM.cpp

フロントエンド最初から書くんじゃなくて、 clang 魔改造、 lib/Target は完全に無視、ってのに笑った。最適化と IR が欲しいから LLVM やってるのかな？という推測はたぶんあってそう。

いやー荒々しくて良いなあ。コードもいいかんじに雑い(まあLLVMもあれだけど、それ以上に)。僕が LLVM IR => befunge トランスレータ書いた時の感覚に近い。いやこっちの方がちゃんとたくさんコード書いてる(そしてそれが逆に驚き)なのだけれども。

上記の推測の根拠は、当然バックエンドはほぼ使いまわし不能だろうし、既存の言語で量子コンピュータを抽象化しきってしまうと単なる古典コンピュータ用言語になってしまうので、当然かなりの量の魔改造が必要、ということから、 LLVM の使いまわせる部分てどこだ？と思ったことから。 C ライクな文法にして clang を使いまわしてるのは、まぁなるほどではある。 #include とか #define とか普通にやっててわらう。 "Quantum C" みたいな話だな… C 的に見ると大幅にサブセットぽいが

あと面白いなあ、と思ったことは、入力より出力の方がはるかに短いこと。これ高級言語で書く意味あるん？？

(20:38)