https://github.com/dyu/ffi-overhead
Results (500M calls)
./run-all.sh 500000000 The results are elapsed time in milliseconds
luajit: 891 905
c: 1182 1182
cpp: 1182 1183
zig: 1191 1190
nim: 1330 1330
rust: 1193 1196
d: 1330 1330
https://irclogs.nim-lang.org/27-05-2018.html#08:35:42
Araq told us already:
seems flawed since Nim has no overhead nor does Rust have any or D.
whatever he is measuring, it's not the "FFI overhead"
maybe it's "cache effects under how the linker arranged functions in memory"
:)
There is no theoretical difference, since Nim compiles to C. Perhaps inlining is the issue??
As for the validity, I have no idea. I'll look and see if it's of sound construction, though.
Ok, it seems decent at least. The Nim code is compiled in release mode, so that's check one. I've seen some benchmarks that claim "Nim is slow", but they're using debug mode unknowingly :P
Anyway, one thing that's slightly off is that the benchmark hello.nim uses int32. Probably, it should use cint.
Anyway, one thing that's slightly off is that the benchmark hello.nim uses int32. Probably, it should use cint.
Indeed, and there is a PR that already corrects it: https://github.com/dyu/ffi-overhead/pull/6