はじめてのにき

さて、等価な変換でレイヤを重ねてくと、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)

[ツッコミを入れる]

2018-03-07

_ コミュニティマーケティング

https://webtan.impress.co.jp/e/2018/03/07/28085

クソ記事ぽいと思ったら普通に全編なるほどそうだなあと思った

(09:57)

_ おもしろまんが

https://blog.toggl.com/world-created-programmer/

おもしろ

(10:13)

_ u7

めも

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)

[ツッコミを入れる]

2018-03-05

_ あたらしいぱそこん

パソコンを買ってみたのでテスト

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)

[ツッコミを入れる]

2018-02-28

_ アパ

一度だけいった時にネトウヨ本みたいなのが置いてあって、なるほど二度と行かないようにしよう、と思ったアパホテルではあるけど、この人はすごい人だなあ

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)

[ツッコミを入れる]

2018-02-26

_ npm

https://cpplover.blogspot.jp/2018/02/npm-57.html

なんか昔書いた色々正しくない適当な文章のうち、nodejsがPHPの受け皿になりつつある、という部分は正しかったんじゃないかって思うことがある、が

(04:50)

[ツッコミを入れる]

2018-02-22

_ kati in android

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)

[ツッコミを入れる]


		2024年 4月
日	月	火	水	木	金	土
	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