Preferences

TazeTSchnitzel parent
It seems Rust has basically no overhead versus C, but it could have negative overhead if you use cross-language LTO. Of course, you can do LTO between C files too, so that would be unfair. But I think this sets it apart from languages that, even with a highly optimised FFI, don't have compiler support for LTO with C code.

I'm not sure LTO is the correct term for this.

What makes C slower than these other languages is that the external function is in a dynamic library. Calling external functions like this is notoriously slow because it involves a double indirection -- every call jumps to the PLT's function entry, which jumps to the actual function.

It's not that hard to do better in C if you load the library manually with `dlopen` and read the function pointer with `dlysym`. In this case, you directly call the function given its address value.

But that's still slower than having the function address "hardcoded" in the machine code, which is what you get when statically linking in C. That's also what the languages with negative overhead do when JIT-compiling (they basically statically link at runtime).

TazeTSchnitzel OP
You must be talking about something different to me. I am referring to using the compiler's LTO option to do LTO. I didn't say that's the only way you could get low overhead.
Right, but traditional LTO is for static linking. How would one even do LTO with a shared library?
TazeTSchnitzel OP
In principle nothing prevents doing it for shared libraries too, if you control them.
Normal_gaussian
For those of us not up on our compilation acronyms - this is Link Time Optimisation.
TazeTSchnitzel OP
Ah yes indeed. LTO means the compiler can do certain optimisations across compilation units (in C/C++ those are your .c/.cpp files, in Rust the unit is the entire crate), notably inlining.
DonHopkins
>negative overhead

underhead

otikik
Overtail

This item has no comments currently.