> No, it's not the exact same external library.<p>It uses the exact same assembly language.<p>> There's an additional Rust library in between that they used, which provides the `FFISafe` type, and that has overhead.<p>Look, I wrote " But the point is that the exact same external library code has a _lower_ cost if called [from C]" and that remains a true statement. It's pretty obvious that I was referring to the shared code, otherwise, it wouldn't have ever been called from C, right?<p>The profiler showed that the identical assembly language itself was taking more cycles when called from C.<p>> There's an additional Rust library in between that they used, which provides the `FFISafe` type, and that has overhead. This is not a standard Rust library, or even one that I'm able to find within a few minutes of googling despite having used Rust for over a decade.<p>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.<p>> Your argument seems to boil down to "Rust claims to be efficient, but it's possible for someone to write inefficient code, and for me to use that code, so therefore those claims are wrong".<p>No, that's not my argument at all. 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++.<p>To me, that looks like a high-cost non-abstraction.
> Look, I wrote " But the point is that the exact same external library code has a _lower_ cost if called [from C]" and that remains a true statement.<p>I don't think you've understood the article at all.<p>The overhead came from the author's own abstractions that were designed to accommodate both the assembly version or the Rust fallback. The assumption was that they take the same types and therefore the abstraction would be zero-cost, but in practice the Rust version had different types and therefore there was extra overhead in the way they were called.<p>If the author had simply done an extern "C" of the function and called it from Rust there wouldn't be overhead.<p>> To me, that looks like a high-cost non-abstraction.<p>The abstractions that caused this probably were not standard Rust library abstractions. The author wrote them as part of the library.<p>You don't need an abstraction at all to just call C functions from Rust. It's build right into the language.<p>If you think the problems in this article are a common Rust failure mode, you haven't understood the article at all. The unique method of calling C functions was something the author wrote, not a standard Rust practice.