ToDo:
https://r25.jp/article/560392031878166383
そうそう、やっぱホリエモンいい人ぽいよね、と思ったけど、よく考えると割と普通のことばっか書いてあった
映画のジャイアンみたいな…
(17:14)
適当に色々走らせてみる。
CPU-avx2-256 50.062899 GFLOPS t=150 CPU-avx2-512 36.600433 GFLOPS t=14 CPU-avx2-1024 41.914810 GFLOPS t=10 CPU-blas-256 245.587644 GFLOPS t=732 CPU-blas-512 359.621543 GFLOPS t=134 CPU-blas-1024 507.372811 GFLOPS t=24 GPU-mine-64 64.069479 GFLOPS t=12221 GPU-mine-256 246.106109 GFLOPS t=734 GPU-mine-1024 137.683075 GFLOPS t=10 GPU-cublas-64 68.099346 GFLOPS t=12989 GPU-cublas-256 1666.332399 GFLOPS t=4967 GPU-cublas-1024 3462.507099 GFLOPS t=162
CPU-avx2 は Haswell 向けになかむらさんの文章見て適当に書いたコード。当時は BLAS とここまで差が無かったと思うし、なんかヘンなので後で見る。
GPU-mine はもっとどうでもいい、本気で適当に書いたもの。おいおいこんな適当なコードで BLAS に勝つんかと思った
GPU 自体は GTX 1060 3GB というやつで、 Pascal 世代らしい。 1152 コアで最大 1.76GHz 。理論は 4TFLOPS らしい?
次は、最近買ったノートPCにて
CPU-avx2-256 37.796423 GFLOPS t=113 CPU-avx2-512 26.427590 GFLOPS t=10 CPU-avx2-1024 36.619350 GFLOPS t=10 CPU-blas-256 4.165613 GFLOPS t=13 CPU-blas-512 4.127086 GFLOPS t=10 CPU-blas-1024 3.944004 GFLOPS t=2 GPU-mine-64 29.070758 GFLOPS t=5545 GPU-mine-256 57.308421 GFLOPS t=172 GPU-mine-1024 20.952593 GFLOPS t=10 GPU-cublas-64 46.641611 GFLOPS t=8897 GPU-cublas-256 505.182081 GFLOPS t=1506 GPU-cublas-1024 1028.495491 GFLOPS t=48
CPU-blas の成績は明らかにおかしい。 GPU は MX150 というやつで、こいつも Pascal 世代らしい。 384 コアで最大 1.04Ghz 。理論(?) 1.127 TFLOPS、かな?
10 万強で 1kg 強の ノート PC で TFLOPS 出てるんだなあ
(22:58)
(09:08)
https://gqjapan.jp/culture/column/20150730/welcome-to-pariah-ville/page/4
最初はキツいなあ、と思ったけど、バランス取れた感じの、いい記事だなあと思った。
(20:06)
Codeforces & Microsoft の量子プロコンで触った。
http://codeforces.com/contest/1002/
最後の問題解けなかったのは、サイズ N の配列を返さないといけないところに、 N+1 個返してたからぽかった。残念すぎる。
問題セットはwarmupも含めてすごく良い感じだったと思う。解けないほど難しい問題はなくて、基本的かつ教育的な、僕にとっては「そういえばそんな話があった気もするなあ……」くらいの問題が並んでいる感じ。そういう全部解かれる前提の問題設計だったのか、そもそも量子情報で「あまりよく知られていなくて、量子性を利用していて面白く、十分に難しく、古典でのシミュレーションで実行できる」みたいな条件がそろう問題ってあまりないのか、まあどっちかというと後者なんじゃないかなと思うけど、それにしても基礎的な問題が多かった印象
ただ D1 と E1 の方が量子の面白さを伝える感じなのに対して、 D2 と E2 はひっかけ問題チックなので、イマイチかなあ…と思った。 E2 が時間かけたのにも関わらず解けなかった問題なので、言い訳くさいけど。
Q# は、言語としてもシミュレータを含めた環境としても、なかなかよくできているなあと思った。古典情報と量子情報の往復の部分とかは、そのまんま自力で書く感じ。量子→古典の移動は、観測を伴ってしまうので、まぁ明示的に書かせるのが良いのではないかと思う。あまりトランスペアレントにしたくないかなと。
一方で古典→量子の移動、要するに Qubit の初期化の部分は、これはなんか適当な状態を自由に作る手段があっても良いのかなあ……と思った。アルゴリズム考えてる時とか、「仮にこういう状態が作れるとしたら、こういうアルゴリズムは作れるだろうか?」と考えてから、「実際その状態、作れるの?」と考えたいこともあるんじゃないかなあ、と。シミュレータならいきなりそういう状態で初期化してくれれば良いし、実機では適当に精度指定すると存在するオペレーションでやってみてくれて、合成できない(オペレーション数が多すぎる場合も含めて)場合はエラーにする、とかで良い気がする。
PrepareArbitraryState というライブラリ関数もあるのだけど、 W state 作る問題で使ってみたら遅すぎるようだった。
(00:50)
https://drive.google.com/file/d/1QlDRAyAN926YoBuBb9auo4WZdhCyh7fC/view
面白い…
(14:16)
名古屋の宿の近くに、死ね金返せ系の落書きがたくさんある旅館があって怖かった
https://www.instagram.com/explore/tags/%E6%97%85%E9%A4%A8%E5%A4%A7%E6%9D%BE/
こういうの実在するんだな……バキの家みたいって思ったら、2chとかでも同じこと言ってて笑った
(14:20)
仕事にも使う予定なので、 Debian は微妙かなあと Ubuntu にすることにして、 16.04 はちょっと微妙問題があったので、 Ubuntu 18.04 でいってみることに
何度もする作業をメモ
最初にすべきこと
scp "i@xxx:.*" . sudo apt-get install ssh screen zsh chsh sudo apt-get install git subversion g++ make gauche ruby python3 python3-pip lv scp -r i@xxx:bin . scp -r i@xxx:lib . zsh git clone git@github.com:shinh/test.git svn co $SVN wrk cd ~/wrk/fake_isatty sh build.sh
sevilwm
apt -i libxrandr-dev cd ~/wrk/sevilwm rsync -avr "i@xxx:wrk/sevilwm/dev" . make sudo cp sevilwm /usr/local/bin
w3m
apt -i libgc-dev libimlib2-dev libncurses-dev scp -r i@xxx:.w3m . cd ~/wrk git clone git@github.com:shinh/w3m.git cd w3m ./configure && m sudo make install
apt-file
apt -i apt-file sudo apt-file update
適当に色々。 sevilwm に切り替える準備
apt -i ghc ocaml rlwrap emacs wicd gkrellm xscreensaver feh apt -i mlterm scp -r i@xxx:.mlterm . sudo vi /usr/share/xsessions/custom.desktop [Desktop Entry] Name=Custom Exec=/etc/X11/Xsession
CUDA
apt -i mesa-utils # follow nvidia's instruction for CUDA... sudo apt-get install -o Dpkg::Options::="--force-overwrite" cuda-9-0 sudo dpkg -i libcudnn*.deb
MLフレームワーク
pip3 install cupy # gcc-7 でコンパイル通らんので編集 # sudo vi /usr/local/cuda/targets/x86_64-linux/include/crt/host_config.h pip3 install cupy pip3 install chainer pip3 install tensorflow
UIM SKK
apt -i uim-skk ddskk uim-pref-gtk3
忘れがちな開発ツールまわりの
apt -i autoconf automake libtool texinfo flex bison glibc-doc libc6-dev:i386 libgcc-7-dev:i386 libstdc++-7-dev:i386 lib32gcc-7-dev valgrind
(20:38)
https://twitter.com/taku910/status/1010082944629727234 などを見てもそうだけど、この用語法が良いかどうかは議論の余地があると思う。
define-by-run が研究時に有利なアプローチなのは間違いないという合意は形成されつつあるようにあると思う。プロダクショナイズ時の整合性の保証と、トレーニング速度の心配が define-by-run で気になることかと思う
define-and-run はデプロイ時に Python のランタイムが必須でなくなり、また、トレーニング時に使ったモデルが正しく使われている保証が取りやすい。ただし
原始的な define-by-run はホスト言語に処理が戻ってくるので、速度が出しにくい。ただ、最適化の余地があって
そもそも、速度が出ないのなら、 Python をコンパイルしちゃえばいいという発想もありえる。これは単に Python を C なりアセンブリに変換するという話ではなくて、 Python 内で記述されたハイレベルなオペレーション群をくっつけていって、アクセラレータ内で完結した実行をしてもらう、という話
「Python をコンパイルする」て語感と実体がだいぶ違うアプローチで、感覚としては CUDA に近いものだと説明している。 CUDA だと、 __global__ てついてる関数はデバイスで実行して、ホスト側に main があってそのデバイスの関数を呼んだりする。同じような感じで、 Python の一部の matmul+activation みたいなところを Python じゃないコードでまとめて実行すれば良い
実際やってるのが Pytorch の @script や、そもそも言語まで変えてしまったのが Swift for TensorFlow 。アクセラレータに投げる部分の抽出と、計算グラフの微分をしたいので、 AST なりなんなり、言語処理系にまあまあ手を入れる必要があると思う。
このへんのアプローチは、気持ちとしては define-by-run のまんまだけど、なんか明らかに事前コンパイルしてる以上、 define-and-run の方が適切な呼び名な気がしてしまうので…… Swift for TensorFlow などは model-as-code と言ってるのだと思う
個人的には model-as-code が正しい方向性に思える
話がそれていく。 Swift for TensorFlow みたいな方向性が正しいとして、欲しい/必要と思う機能として
あたりを考えてると、 mypy と tangent で(どちらもよく知らないが)、一応 Python をコンパイルして使う、てのは要件を満たしそうな気もする
もっとそれていくけど、なんか雑談してると、 XX が作ってる深層学習向けプロセッサー、みたいなことを言うと、「TPUみたいなやつ?」と聞いてくる人がいたりする。深層学習向けに独自に作る価値がある計算装置として
トレーニング中は数日とかかけて、何回も同じ計算をするわけで、その計算は、例えば10分とかじっくり時間をかけて最適化しても割にあう。本質的に Python のオーバヘッドからは既にほぼ無縁な TF のグラフだけど、ターゲット向けにゆっくりコンパイルしてさらに速くする方がより良いでしょ、というのが XLA 。 ONNX を入力としてわいわいやってるのが NNVM
いろいろ話はあるけど、トレーニング向けは益がそんなに大きくないのかなあ、という気はしている。けどある程度の命令数を GPU でないアクセラレータでやるのであれば、なんかしらこういうレイヤのものは必要になるだろうしな
(20:55)
http://shinh.skr.jp/m/?date=20100915#p01
の続き。六本木を出る前に書いておこうかと思った
あと阿部っていう寿司屋が、なんか立派ぽい寿司(偽)が安いので、ランチがお得感がある
(17:32)
そういえば、 numpy とか tensorflow とか毎度 import するのめんどくさいなあ、でも repl 起動した時に自動的に import されてしまうのも遅くて不便だなぁ、と思ったので、参照されたら遅延ロードする、ってものを書いてみた
https://github.com/shinh/test/blob/master/pythonrc
便利
PYTHONSTARTUP=$HOME/test/pythonrc exec python3
などとして使う
(18:13)
http://b.hatena.ne.jp/entry/s/anond.hatelabo.jp/20180624222908
こわすぎる話
もちろん殺人はダメに決まってるけど、はてぶのコメント見てる印象では、趣味で荒らしてるうざい人、て感じじゃなくて、真摯に荒らしてる、たぶん病院に行った方が良かった人、なんだろうかなあ……
ネット上の(自分にとって)間違った言論を全て消すことはできないから、そう努力しても徒労に終わるだけだし、相手がどういう人かあまりわからないし、そもそも間違った言論を全て消すてのもディストピアだし、で、どんな相手だろうとネットで攻撃的な応対する意味とかないなあ、と思う。古い言いつたえだけど「荒らしは放置」て原則は正しいな
(11:03)
昔の VMware はバイナリ書き換えでシステムコール命令をフックしていたという話
Valgrind はメモリの読み書きのフックを全命令エミュレーション+JITで実現
NaCl は SFI では一番成功しかけた例
ではないかと思う。それぞれ、 CPU レベルでの hypervisor サポート、 clang/LLVM レベルでの変更、 hardware isolation で意味ない技術になった
思うにこういう、一レイヤ掘ったところでサポートすればもっと正しい解になるけど、上位レイヤの筋悪技術でも割といけるぜ、てのが好きなんだなぁ…と思う
他でいうと、 C++ TMP の一番論外な部分は D の CTFE なり C++ constexpr で実現された、とか C99 の数学関数は __builtin_classify_type がなくても __typeof__ と const 計算と三項演算子でなんとか実装できるぜ……とかも似たようなものだと思う
教訓としてはちゃんと適切なレイヤ掘れって話だと思うけど、まぁこの手の近視眼的なハックはひどく楽しいんだよな
(04:18)
https://pytorch.org/2018/05/02/road-to-1.0.html
なにやら trace のやつと @script のやつもう ready になる寸前なんだな。
(01:08)
tailsさんの解を理解したかったので読んだ。他の人はたぶん山登ったり焼いたりしてる中、貪欲だけで長期間トップに立ってて、最後まで良い成績で異様だったので。最終版はややこしいので、頭角を示しはじめた頃の
https://yukicoder.me/submissions/261010
を。ちゃんと読んでみるとシンプルで、
とかだけ。言われてみればなるほどなんだけど、これで高得点なのはすごいなあ。最終版では余ったのを捨てない、ループの向きを回転反転の8パターンでやる、2つ目の貪欲のパラメータを適当に変えて時間を使い切る、くらいの差分を見てとった。
うーんすごいな
(17:19)
のふたつはゴールだったんだけど
http://shinh.hatenablog.com/entry/2018/06/17/203604
へのブクマとかtwitterとか眺めてると、グーグル < PFN みたいなのが結構あるし、他社については語られないし、なかなか難しい。他社も本当にすごい良さそうだったんだけど、具体的には書かないべきだろうしなぁ。あ、逆に僕が面接受けに行った会社の人はそのへんの情報は自由に共有してもらっていいです。
グーグルへのもう一つのどうしようもない不満というと、どうしても大企業なので one of them になっちゃう、というのがあったけど書いてなかった。あの会社で one of them にならない方法は Jeff Dean になるしかなく、無理ゲー。まあ完全に大企業の安定感とのトレードオフだし、僕は安定指向なのでそっちの方がいいや、て思ってたけど、逆の方もやってみたいな……と隣の芝に行ってみたというような。
その例をとってもそうだけど、当たり前だけど会社間に全順序つかないなぁ、というようなことは何度も思った。
人によってあうあわない、タイミングによってあうあわないあるわけで、グーグルでプロジェクト変える程度に気楽に、小さい会社も含めてジョブホップできるといいなぁ、と思う。そうなるとグーグルジャパンも焦って給料増やすかもしれないし。今までは基本的にグーグルが取っちゃうから他が給料上げてた構図があったと思う。シリコンバレーとかなんかそういう感じで回ってるよね。
11年も一つの会社に行っておいてなんだけど、まあみんなもっと動(く|ける)と良さそうだよね
(15:35)
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)
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)
https://github.com/epiqc/ScaffCC
フロントエンド最初から書くんじゃなくて、 clang 魔改造、 lib/Target は完全に無視、ってのに笑った。最適化と IR が欲しいから LLVM やってるのかな?という推測はたぶんあってそう。
いやー荒々しくて良いなあ。コードもいいかんじに雑い(まあLLVMもあれだけど、それ以上に)。僕が LLVM IR => befunge トランスレータ書いた時の感覚に近い。いやこっちの方がちゃんとたくさんコード書いてる(そしてそれが逆に驚き)なのだけれども。
上記の推測の根拠は、当然バックエンドはほぼ使いまわし不能だろうし、既存の言語で量子コンピュータを抽象化しきってしまうと単なる古典コンピュータ用言語になってしまうので、当然かなりの量の魔改造が必要、ということから、 LLVM の使いまわせる部分てどこだ?と思ったことから。 C ライクな文法にして clang を使いまわしてるのは、まぁなるほどではある。 #include とか #define とか普通にやっててわらう。 "Quantum C" みたいな話だな… C 的に見ると大幅にサブセットぽいが
あと面白いなあ、と思ったことは、入力より出力の方がはるかに短いこと。これ高級言語で書く意味あるん??
(20:38)
これ高級言語というよりマクロアセンブラじゃないか
(20:58)
https://www.youtube.com/watch?v=uNjxe8ShM-8
SIGBOVIK てのがあるのかー。前似たようなの見たけどそれより楽しそう
(22:48)
前 | 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扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。