Why is calling my asm function from Rust slower than calling it from C?

1. You've come up with your own unique definition of "zero cost" which isn't what the term means, at least as popularized by C++ where the concept of "zero cost abstractions" comes from. It means zero runtime cost, not zero cognitive cost.

2. Rust generally has more "zero cost abstractions" than C++ in terms of shifting traditional runtime checks into compile-time checks (e.g. while unique_ptr exists in Rust as Box, it's far more rarely used because ownership is easier to transfer).

3. Rust generally has faster defaults in the standard library so the abstractions are lower-cost than equivalents in C++ (e.g. C++ took forever to add a hash table via unordered_map and then proceeded to really fuck up the definition to inhibit high performance designs despite this being raised during standardization & haven't since revisited the issue).

4. Rust offers far more opportunities for "zero cost abstractions" than C++. Notably it's ownership rules prevent aliasing which allows the compiler to do more aggressive optimizations that can't generally be done in C++. It provides abstractions like NonNullPointer and NonZero so that unused bit patterns can be leveraged for enums (e.g. Option is the size of a raw pointer but in C++ it's harder to pull off). Functional style and iterators are implemented to be aggressively inlined and overheads like bounds checking elided by the compiler, whereas C++ can't elide as easily and various bounds checks have to be inserted. Could go on and on.

Anyway, Rust as the base language vs C++ has simpler cognitive abstractions, it has more zero cost abstractions, and it has more efficient abstractions overall, both in the language and the standard library.

> The profiler showed that the identical assembly language itself was taking more cycles when called from C.

No, again, it showed that using a certain wrapper type around the same assembly had more overhead. My argument is that there's no reason to assume that this single type is representative of the entire ecosystem. I don't understand what you could possibly mean if that's not what you're saying.

> The point is that they did the absolute normal expected thing in Rust, and it slowed down the external assembly language library, and after a _lot_ of digging and debugging, they changed the Rust code to be a lot less flexible and more convoluted, and now the assembly language is almost as fast as when it is called from C.

> Look, the people doing this _obviously_ know Rust, and it took them a _long_ time, and some _really_ ugly concrete low-level concrete code, to take external code and make it perform almost as well as if it had been called from C++.

Sure, and you'd probably need a lot of similar ugliness to do the same in reverse to call a random Rust library that wasn't explicitly designed to be called from C/C++. You seem to be inferring that Rust on the whole can't be performant because the boundary between C/C++ isn't as easy as staying on the same side of the boundary, but that works both ways. If your argument is "I only want to use a language that lets me call all of these C/C++ libraries I want", that's totally reasonable. That's not the same as "Rust doesn't have zero cost abstractions" though, unless you think "calling a C/C++ library directly" is what abstraction means.

> Look, the people doing this _obviously_ know Rust, and it took them a _long_ time, and some _really_ ugly concrete low-level concrete code, to take external code and make it perform almost as well as if it had been called from C++.

> To me, that looks like a high-cost non-abstraction.

I don't understand this argument at all. You don't think that a type called `WithOffset` that wraps a pointer to provide an offset is an abstraction? From what I can tell, they were using an abstraction that was implemented inefficiently, and they switched to one written efficiently. I guess we just have completely incompatible definitions of what "abstraction" means, given that from my perspective, you genuinely seem to be arguing that the presence of this one abstraction that someone wrote being inefficient happens to be representative of the entire language and ecosystem.