No.51
周りに居たら嫌だなぁ
周りに居たら嫌だなぁ
次世代言語27 Nim Zig Pony Carbon Gleam
レス数: 87
概要: 書いたコードがどんな機械語になってるか、確認してない層が一定数存在するって事？ 周りに居たら嫌だなぁ
周りに居たら嫌だなぁ
No.52
最適化ビルドするとまるで想像通りじゃなくてびびったりはする
No.53
だよね。
No.54
俺特殊なハードウェア用のコンパイラとか作ってたんだけど
コンパイラ作ってようやくCがちゃんと理解できたよ
マジでコンパイラ作らないとわらないと思う
No.55
ISBN 4797337958
No.56
これはまあまあおすすめ
ただ32bitCPU時代に書かれた本なのでそこが微妙なのと
理論的なものがほとんどなく構文解析もJavaCC使ってるし
コード生成も毎回演算結果をスタックにpushするようなことをやってた気がする
allocaも自前で実装するし
ただCのような言語をアセンブリ言語へコンパイルするための勉強としては悪くない
No.57
racc使う予定だったらしい
No.58
No.59
No.60
No.61
誤植が猛烈に多いのも練習問題のような気がしてきますよ。
No.62
このあたりは偏執狂のRustの方が上手だな。
いっそのこと参照型のゼロ値は禁止すればいいのに。
No.63
std/options で
ひとまずOK じゃないか ?
No.64
https:
No.65
not nil がデフォルトになるとあるね。
No.66
2.0がいつ出るかなんて全く不明
1.8.0の次は1.10.0
次は1.12.0となって。。。
恐らく5年以上先 ?
No.67
なんでなんだろう？
No.68
実行時じゃないとサイズがわからないことがあるし、スタック上に動的にメモリ領域を確保できるようにするとかなり大きめにスタックを確保しなくてはならくなるだろうし。
No.69
Forthみたいなスタック指向の言語とは違うよね
No.70
関数のABIとは別に仮想的なローカルスタックを扱えるかんじ？
No.71
COBOL++でしょ
No.72
スタックフレームならではの特性をコードに明記できる、といったイメージ。
例えばスタックにあるインスタンスしか受け付けない(参照)引数とかあれば、shared ptrとかunique ptrの参照渡しも安全に使える。
Rustがそこそこいい感じなんだけど、なんか中途半端。
No.73
Rustなら実用上はCopyで十分
No.74
rustの話は向こうのスレでお願い
No.75
そういうのが中途半端だと言っている。日本語も読めないのかよ。
No.76
次スレはこれらの言語を入れてください
Zig
https:
Jakt
https:
No.77
どんな処理系かな
No.78
borrow checkerはなく、代わりにARCを使って実行時にメモリ管理しようとしてるっぽい
なんでRustやZig使わないんだろうと気になったけど、自作したSerenityOSのためのエコシステムはできるだけすべて自作したい、くらいの動機みたい
参考:
https:
まあZig未満のドマイナー言語にとどまりそう
No.79
jaktはC++へのトランスパイラ、ってのも特徴
SerenityOSはC++で作ってたから、C++トランスパイラにすれば移行しやすかったってことだろう
No.80
No.81
Language x10 x100 x200 x400 Memory Comment
--------------------------------------------------------------
Zig 0.118 1.073 2.113 4.203 3.2MB (std.HashMap, caller-hash by Context(Fnv1a_64))
Nim(clang) 0.211 1.171 2.245 4.372 4.2MB (CustomCountTable,LTO,ARC,caller-hash) New
C(gcc) 0.136 1.146 2.271 4.531 2.0MB (optimized.c,binary IO,jemalloc,O4,LTO)
C(clang/LLVM) 0.137 1.147 2.280 4.544 2.0MB (optimized.c,binary IO,jemalloc,O3,LTO)
Go 0.152 1.233 2.428 4.832 3.9MB (caller hash,better loop)
Go 0.164 1.346 2.654 5.279 3.8MB (caller hash)
Rust(LLVM) 0.154 1.425 2.838 5.674 2.6MB (optimized-customhashmap,O3,LTO,caller-hash)
以下、caller-hashではない
Go 0.085 0.366 0.693 1.319 61.9MB (parallel.go,reserve 65536/2)<--マルチスレッド
Nim(clang) 0.218 1.255 2.401 4.691 4.2MB (CustomCountTable,LTO,ARC) New
Zig 0.162 1.493 2.970 5.935 4.6MB (std.StringHashMap)
Go 0.182 1.563 3.063 6.097 3.8MB (customhash.go,reserve 65536)
Rust(LLVM) 0.214 1.725 3.396 6.715 3.5MB (optimized,fxhash,O3,LTO)
Nim(clang) 0.316 2.241 4.371 8.633 4.2MB (optimized.nim,std/CountTable,65536,LTO,ARC,FNV) New
Nim(clang) 0.332 2.387 4.652 9.152 4.2MB (optimized.nim,std/CountTable,65536,LTO,ARC) New
zig 0.10.0-dev/gcc 12.2.0/clang 15.0.0/Nim 1.6.8/go go1.19.1/rust 1.64.0
CPU Zen3@boost~4.75GHz
https:
https:
今回の検証では、「C」は定点観測用として固定。
Nim/CustomCountTableはinc呼び出しの引数string copyを抑制。
Nimが想像より遥かに速くて「Cと同程度」以上の結果が出た。
No.82
https:
Language 10^5 10^6 Comment
----------------------------------
C++(clang) 0.032 1.029 (O3,LTO,vector,fastmod)
Nim(clang) 0.033 1.031 (O3,LTO,Seq,fastmod)
Nim(gcc) 0.041 1.339 (O4,Seq,fastmod)
C++(gcc) 0.042 1.502 (O4,vector,fastmod)
以下、fastmodではない
Odin(LLVM) 0.073 3.784 (o:speed,[dynamic]int)
Nim(clang) 0.074 3.784 (O3,LTO,Seq)
C++(clang) 0.074 3.785 (O3,vector)
Cython(clang) 0.089 3.797 (O3,libcpp.vector)
Nim(gcc) 0.083 4.410 (O4,Seq)
C++(gcc) 0.085 4.412 (O4,vector)
Zig(LLVM) 0.083 4.410 (OReleaseFast,ArrayList)
Julia(LLVM) 0.254 4.583 (JIT,O3,Int[])
Python(Numba) 0.602 5.236 (JIT,list[int])
PyPy 0.162 7.046 (JIT,list[int])
Cython(clang) 0.696 39.603 (O3,list[int])
Python 1.187 75.740 (list[int])
https:
https:
zig 0.10.0-dev/gcc 12.2.0/clang 15.0.2/Nim 1.6.8/Odin dev-2022-10-nightly/
julia 1.8.2/Python 3.10.7/PyPy 7.3.9/Cython 0.29.32/numba 0.56.2
CPU Zen3@boost~4.75GHz
No.83
Juliaは確かに速いが、他との比較は最適化オプションしだい。
動的配列/リストのベンチになるかと思ったが、やってみたらgccが振るわない。
原因はmodulo計算の最適化の違い？
https:
ZigはLLVMのmodulo最適化をトリガー出来なかったか。
OdinはLLVM AOTコンパイラとしての性能を引き出せている(今回は)
まだ言語機能の特徴をつかんでいないが、映画、ゲームグラフィックス分野で使う様な
ライブラリが最初から入っているのが売り？
Nimは殴り書きとか、書き捨てとか、簡潔に書けて、gcc/clangの速い方を選べて、
fastmodの様なC++「header only」のライブラリを手軽に利用できるのが良い。
Cythonも慣れたらNimと同じように出来るのだろうか。
No.84
No.85
https:
200万ドル程度と見積もられる資金はMicrosoftが協力
参考
Faster-Cpython Microsoft
Pyjion Microsoft
Cinder Instagram/Facebook/Meta
GraalPy Oracle
Pyston Dropbox->pyston-lite
Ruby3 3倍速->rya
No.86
No.87
