ToDo:
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)
https://webtan.impress.co.jp/e/2018/03/07/28085
クソ記事ぽいと思ったら普通に全編なるほどそうだなあと思った
(09:57)
めも
i@u7 11:45 ( '-') df -h Filesystem Size Used Avail Use% Mounted on udev 10M 0 10M 0% /dev tmpfs 785M 1.1M 784M 1% /run /dev/sdb1 159G 106G 46G 70% / tmpfs 5.0M 8.0K 5.0M 1% /run/lock tmpfs 2.9G 106M 2.8G 4% /run/shm /dev/sda5 455G 409G 23G 95% /home cgroup 12K 0 12K 0% /sys/fs/cgroup tmpfs 785M 12K 785M 1% /run/user/1000 /dev/loop0 290M 290M 0 100% /mnt/cdrom
(11:45)
パソコンを買ってみたのでテスト
model name : Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz
6コア12スレッド、メモリ8GB(4*2で2個空いてるスロットある)、ディスク1TB(なんかSATAぽいケーブルがあまってる)、 GeForce GTX 1060 3G (ちょっと cuda ってみたくなった)
世代的にはcoffee lakeで、なんかもちょい待ってもよかったなとは思った、というかskylakeからspectreのreturn stackの傷が深くなってるらしいから、なんかやっぱもちょい待っても良かったんじゃ
8700kの方同じ世代で良いCPUなのだけど、なんか動いてない時の周波数とturbo boost時の差が8700の方が広いので、こっちの方がご家庭向けだろ、てことで
i5 i3 は物理コア数とスレッド数同じにする風潮があるらしく、なんかビルドとかしてるのが一番CPUを使ってる時な気がする僕のワークロードには向かない気がした。もちょい古い世代でも別に良かった気がするのだけど、なんか値段とか見てるとkaby普通にコスパ良かった
というか一瞬XeonとかSkylake-Xも検討したけど、なんか微妙だなあと。AVX-512とかどうせ今は速くなくて実際速くなる頃には家庭向けのにも実装されてそうだしな。RyzenはSGX遊んでみたかったので落ちた
TFのmatmulで500Gflopsくらい出てて、Haswellさんの倍くらい出てる。もともと理論430Gflopsくらいで、今はスーパースカラの具合が変わってなければ880Gflopsくらい?だとするとまあ、ちょうどそんなもんかという感じ
値段はパソコン工房で12万6千円
cpuinfoのdiffを見てみると
["art", "3dnowprefetch", "invpcid_single", "kaiser", "fsgsbase", "mpx", "rdseed", "adx", "smap", "clflushopt", "intel_pt", "xsavec", "xgetbv1", "xsaves", "ida", "hwp", "hwp_notify", "hwp_act_window", "hwp_epp"]
MPX以外よくわからん。てか特に 3dnowprefetch てなんや
(01:11)
http://www.nurs.or.jp/~ogochan/essay/archives/5121
最後に書いてあるけど、自由人側にいるプログラマて割と特殊な業態だよなあ。未だに「何やってんの」「プログラマです」「あ、SEじゃないんだね(お気の毒に)」みたいな会話ある気がするしなあ
(01:13)
一度だけいった時にネトウヨ本みたいなのが置いてあって、なるほど二度と行かないようにしよう、と思ったアパホテルではあるけど、この人はすごい人だなあ
https://woman.type.jp/wt/feature/9119
(12:14)
http://news.livedoor.com/article/detail/14362334/
http://buzzap.jp/news/20180227-jaycee-net-kaiken-uyokun/
こういうの本当にやるんだなあ、すごいなあ。
左派も似たようなのやってそうだ
しかし発言見るとあまり姑息じゃないっていうか、ストレートすぎて工作として機能してんのかこれ
(12:22)
https://cpplover.blogspot.jp/2018/02/npm-57.html
なんか昔書いた色々正しくない適当な文章のうち、nodejsがPHPの受け皿になりつつある、という部分は正しかったんじゃないかって思うことがある、が
(04:50)
http://note.qidong.name/2017/08/android-kati/
たまたま見つけた
中国語だけど英語に翻訳して読むと内容は極めて正しくてすばらしい。機械翻訳だけど
When used alone, it barely works for ordinary small projects. When faced with a complex, multi-nested Makefile, it often fails to support it and presents a variety of problems. Of course, it can be understood as, it is only designed for Android. In short, it is not recommended to use kati in any project other than Android .
という説明、つまり Android のためだけに作られてるから他で、特に submake があるようなプロジェクトでは有用でない、というのは本当にそう。
ドキュメントがまともにないのでありがたい
(00:32)
https://noidea.dog/blog/delegation-means-not-answering-all-the-questions
マネージャは下の人の自主性を伸ばすように、答えられる質問にもあえて答えないようなことをした方が良いという話
なるほどなあ
(11:41)
大変な商売だなあと思う
でまあこれすごく良い記事だなあと思った
http://tech.nikkeibp.co.jp/atcl/nxt/column/18/00138/021300004/
ついでに同じ人の第三の量子コンピュータについての説明もとても良い
http://tech.nikkeibp.co.jp/it/atcl/watcher/14/334361/112400961/
(12:10)
https://x86opti.connpass.com/event/76947/
自分の発表、XLAの話と言っても機械学習とかTensorFlowとかXLAとか別に興味ないだろう、ということですっとばして、ざっと背景説明→XLAからCPUに落ちたコードを眺める、という感じにした。
結果として、準備が足りなかったこともあって、まあそうですよねーということがわかっただけで、あまり面白くない感じになってしまった
http://shinh.skr.jp/slide/tfxla/000.html
もうちょいハイレベルだとXLA自体は結構面白いと思うトピックもあると思う。命令スケジューリングのところを読みたかったのだけど、間に合わなかったんだよな。読んでいたとしても最適化と若干あわない話なので説明してなかった気がするけど
(12:29)
前回は喉元すぎて痛みを忘れたぽいので記録
痛くないだけで世界が美しく見え、真心ブラザーズのSTONEの心持ちです。
http://j-lyric.net/artist/a006b67/l01b132.html
(01:16)
前 | 2025年 3月 |
次 | ||||
日 | 月 | 火 | 水 | 木 | 金 | 土 |
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扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。