5 ms·
Looking at the c ffi improvements posted, I thought I'd check if there were improvements. Time in ms to call a c function 2 billion times (lesser is better).
by dyu- 10y ago
Looking at the c ffi improvements posted, I thought I'd check if there were improvements.
Time in ms to call a c function 2 billion times (lesser is better).
95536 - go 1.1.2
130105 - go 1.8.0
It is a rather crude example:
// plusone is the ffi
int x = 0;
while (x < 2000000000) x = plusone(x);
Here's the source https://github.com/dyu/ffi-overhead https://github.com/dyu/ffi-overhead
With other programming languages:
c:
4778
nim:
4746
rust:
5331
java7:
17922
java8:
17992
go:
130105
(edited for formatting)
- dpc_pw 10y agoSmall stacks used for goroutines don't play well with calling C functions which assume huge stacks. That's price you pay for having nice scalability story. There might be other issues, which come from the fact that Go has elaborated runtime.
- dyu- 10y agoYea it was a toy example. Still the overhead is steep for applications that call c ffi often. The workaround is usually to batch your computations on the c-side (micro-rpc) and minimize the calls (like cockroachdb is doing)
- michaf 10y agonim is faster at calling c routines than c? That seems interesting... But probably the measurement errors are larger than 1%?
- dyu- 10y agoThey're basically the same (its just a measurement error as you said). Afterall, nim generates c files. What's interesting is the nrvo optimizations that nim generates under the hood without much effort from the developer (on non-trivial codebases).