3 ms·

> someone writing a library with a costly abstraction That's not what happened here. > it's not like C++ doesn't have some costly abstractions This is simult

by zephen 10mo ago

> someone writing a library with a costly abstraction That's not what happened here. > it's not like C++ doesn't have some costly abstractions This is simultaneously both completely orthogonal to my observation that the Rust FFI is borked, and a great example of a problem that wouldn't happen in C++, because in C++ you could completely ignore the costly abstractions if necessary.

saghm 10mo ago
> > someone writing a library with a costly abstraction > That's not what happened here. Yes it is. Where do you think the `FFISafe` type that they used came from? It's not anything inherent to how Rust does FFI; it's a type someone wrote in an attempt to try to provide an abstraction, and that abstraction happened to have a cost. There's absolutely no reason anyone has to use it in order to do FFI in Rust.
- zephen 10mo ago
  The extra time was being taken up in the identical assembly language function. Fixing it took wizardry.
  - saghm 10mo ago
    The time was taken by the code around the assembly language. It was an abstraction someone wrote in a way that happened not to be efficient. The ability of someone to write a costly abstraction doesn't take away from Rust any more than the possibility of doing that in C++ would from whether C++ has them.
    - Dylan16807 10mo ago
      It was caused by the code around it, but the actual CPU cycles stalled out in the assembly language, making it much harder to find the problem. Is how I understood the post. Anyway there's noting wrong with rust FFI. The overhead was because this function wanted to support two options and didn't implement that in the best way.
Aurornis 10mo ago
> That's not what happened here. Yes, it's what happened here. The article is about debugging the author's own abstraction types that had some incorrect assumptions. You do not need these wrapper types to call C functions. If the author had removed the complex extractions and called the extern "C" function directly (as is standard in Rust) there would not be the additional overhead.

by zephen 10mo ago

saghm 10mo ago

> > someone writing a library with a costly abstraction > That's not what happened here. Yes it is. Where do you think the `FFISafe` type that they used came from? It's not anything inherent to how Rust does FFI; it's a type someone wrote in an attempt to try to provide an abstraction, and that abstraction happened to have a cost. There's absolutely no reason anyone has to use it in order to do FFI in Rust.

zephen 10mo ago
The extra time was being taken up in the identical assembly language function. Fixing it took wizardry.
- saghm 10mo ago
  The time was taken by the code around the assembly language. It was an abstraction someone wrote in a way that happened not to be efficient. The ability of someone to write a costly abstraction doesn't take away from Rust any more than the possibility of doing that in C++ would from whether C++ has them.
  - Dylan16807 10mo ago
    It was caused by the code around it, but the actual CPU cycles stalled out in the assembly language, making it much harder to find the problem. Is how I understood the post. Anyway there's noting wrong with rust FFI. The overhead was because this function wanted to support two options and didn't implement that in the best way.

Aurornis 10mo ago

> That's not what happened here. Yes, it's what happened here. The article is about debugging the author's own abstraction types that had some incorrect assumptions. You do not need these wrapper types to call C functions. If the author had removed the complex extractions and called the extern "C" function directly (as is standard in Rust) there would not be the additional overhead.