Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

ohadravid.github.io

Post reply on HN
Print view View original

11–20 of 43 posts

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

#11

Post by zephen »

saghm wrote: post #9
zephen wrote: post #7

Earlier quoted context omitted.

Sure, but languages and the problems we solve with them are both multifaceted, so simply pointing to one tool and saying "this is better than the one you have in your toolbox" is fine, but the plural in "zero cost abstractions" kind of implies that most or all the tools are at parity or better.

It sounds like you're saying that you consider seeing this single instance of someone writing a library with a costly abstraction to be indicative of the entire language ecosystem not fitting the paradigm. This is kind of hard to take seriously; it's not like C++ doesn't have some costly abstractions as well way more embedded into the language itself (e.g. exceptions).

> 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.

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

#12

Post by saghm »

zephen wrote: post #10
saghm wrote: post #8

Earlier quoted context omitted.

I've never understood that to mean that every possible abstraction would be zero cost, but that the language itself provides abstractions that are zero cost. I'm not sure how you could avoid having external libraries ever implement an abstraction with a cost. I honestly can't tell from this article alone what library the type `FFISafe` is from, but it's not from std. (As an side someone whose spent a lot of time in t…

> I've never understood that to mean that every possible abstraction would be zero cost, but that the language itself provides abstractions that are zero cost. To me, "zero cost abstractions" means that you should use the language, because even the fancy abstractions it provides are free. Which presupposes that the language designers _believe_ that abstractions _and_ performance are both _important_. Judging by all t…

> But the point is that the exact same external library code has a _lower_ cost if called from the non-abstract horror of a language C, and the (partial) fix for that is really ugly looking low-level Rust crap that that took a _long_ time to figure out and is the exact opposite of an abstraction, and the full fix is not even known yet.

No, it's not the exact same external library. 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. It's not clear to me why you think this is necessarily representative of Rust rather than one specific library; someone could just as easily wrap a C library in another C library in a way that adds overhead, and it would be equally nonsensical to cite that as an argument that C isn't efficient.

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".

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

#13

Post by saghm »

zephen wrote: post #11
saghm wrote: post #9

Earlier quoted context omitted.

It sounds like you're saying that you consider seeing this single instance of someone writing a library with a costly abstraction to be indicative of the entire language ecosystem not fitting the paradigm. This is kind of hard to take seriously; it's not like C++ doesn't have some costly abstractions as well way more embedded into the language itself (e.g. exceptions).

> 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.

> > 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.

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

#14

Post by zephen »

saghm wrote: post #13
zephen wrote: post #11

Earlier quoted context omitted.

> 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.

> > 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.

The extra time was being taken up in the identical assembly language function.

Fixing it took wizardry.

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

#15

Post by zephen »

saghm wrote: post #12
zephen wrote: post #10

Earlier quoted context omitted.

> I've never understood that to mean that every possible abstraction would be zero cost, but that the language itself provides abstractions that are zero cost. To me, "zero cost abstractions" means that you should use the language, because even the fancy abstractions it provides are free. Which presupposes that the language designers _believe_ that abstractions _and_ performance are both _important_. Judging by all t…

> But the point is that the exact same external library code has a _lower_ cost if called from the non-abstract horror of a language C, and the (partial) fix for that is really ugly looking low-level Rust crap that that took a _long_ time to figure out and is the exact opposite of an abstraction, and the full fix is not even known yet. No, it's not the exact same external library. There's an additional Rust library i…

> No, it's not the exact same external library.

It uses the exact same assembly language.

> There's an additional Rust library in between that they used, which provides the `FFISafe` type, and that has overhead.

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?

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

> 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.

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.

> 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".

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++.

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

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

#16

Post by Aurornis »

zephen wrote: post #5
saghm wrote: post #4

Earlier quoted context omitted.

The point of Rust is ostensibly to provide a safer version of C++-like semantics, not necessarily to avoid the same level of complexity. Especially if you're directly using unsafe code (which is necessary in some cases, like FFI), it's not really clear to me that Rust was "meant" to be doing something wildly different here. The large majority of the code not needing to use unsafe will still be better off even if this…

This is all well and good, but "zero cost abstractions" implies, well, that you're crawling _up_ the abstraction pyramid, not lost in twisty little side passages.

> but "zero cost abstractions" implies, well, that you're crawling _up_ the abstraction pyramid, not lost in twisty little side passages

The zero cost refers to the runtime cost, not the programming complexity.

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

#17

Post by kelseyfrog »

Aurornis wrote: post #16
zephen wrote: post #5

Earlier quoted context omitted.

This is all well and good, but "zero cost abstractions" implies, well, that you're crawling _up_ the abstraction pyramid, not lost in twisty little side passages.

> but "zero cost abstractions" implies, well, that you're crawling _up_ the abstraction pyramid, not lost in twisty little side passages The zero cost refers to the runtime cost, not the programming complexity.

What's a language with zero complexity-cost abstractions?

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

#19

Post by eptcyka »

kelseyfrog wrote: post #17
Aurornis wrote: post #16

Earlier quoted context omitted.

> but "zero cost abstractions" implies, well, that you're crawling _up_ the abstraction pyramid, not lost in twisty little side passages The zero cost refers to the runtime cost, not the programming complexity.

What's a language with zero complexity-cost abstractions?

Natural language. It's a language interpreted by LLMs. It is really high level.

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

#20

Post by Aurornis »

zephen wrote: post #10
saghm wrote: post #8

Earlier quoted context omitted.

I've never understood that to mean that every possible abstraction would be zero cost, but that the language itself provides abstractions that are zero cost. I'm not sure how you could avoid having external libraries ever implement an abstraction with a cost. I honestly can't tell from this article alone what library the type `FFISafe` is from, but it's not from std. (As an side someone whose spent a lot of time in t…

> I've never understood that to mean that every possible abstraction would be zero cost, but that the language itself provides abstractions that are zero cost. To me, "zero cost abstractions" means that you should use the language, because even the fancy abstractions it provides are free. Which presupposes that the language designers _believe_ that abstractions _and_ performance are both _important_. Judging by all t…

> if called from the non-abstract horror of a language C, and the (partial) fix for that is really ugly looking low-level Rust crap that that took a _long_ time to figure out and is the exact opposite of an abstraction,

In case it's not clear, the FFISafe abstraction is not a Rust standard library feature. It's a wrapper type that the author created within their library to bypass some compiler warnings:

https://github.com/memorysafety/rav1d/blob/25e5574/src/ffi_s...

If you want to call C functions from Rust it's as simple as writing an extern block and then calling the function, though you'll have to put the call in an unsafe block because obviously the Rust compiler can't make safety guarantees across that boundary.

The Rust docs for extern are concise: https://doc.rust-lang.org/std/keyword.extern.html

Post reply on HN