4 ms·

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 t

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.

Normal_gaussian 4y ago
For those of us not up on our compilation acronyms - this is Link Time Optimisation.
- TazeTSchnitzel 4y ago
  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 4y ago
>negative overhead underhead
- otikik 4y ago
  Overtail
moefh 4y ago
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 4y ago
  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.
  - moefh 4y ago
    Right, but traditional LTO is for static linking. How would one even do LTO with a shared library?
    - TazeTSchnitzel 4y ago
      In principle nothing prevents doing it for shared libraries too, if you control them.

Normal_gaussian 4y ago

For those of us not up on our compilation acronyms - this is Link Time Optimisation.

TazeTSchnitzel 4y ago
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 4y ago

>negative overhead underhead

otikik 4y ago
Overtail

moefh 4y ago

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 4y ago
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.
- moefh 4y ago
  Right, but traditional LTO is for static linking. How would one even do LTO with a shared library?
  - TazeTSchnitzel 4y ago
    In principle nothing prevents doing it for shared libraries too, if you control them.