Why is calling my asm function from Rust slower than calling it from C?
ohadravid.github.io
Why is calling my asm function from Rust slower than calling it from C?
1–10 of 43 posts
Re: Why is calling my asm function from Rust slower than calling it from C?
#2 For example, before we had something like:
top: *const FFISafe>
We can change that to:
top: WithOffset>
Re: Why is calling my asm function from Rust slower than calling it from C?
#3Not related to the topic, but seeing this tidbit in the article took me by surprise;
> PSA: if you don’t see syntax highlighting, disable the 1Password extension.
This linked to the following discussion that's been ongoing for over a week (with acknowledgement from 1password that they're looking into it but as far as can tell no ETA on the fix or explanation for why it's happening in the first place):
https://www.1password.community/discussions/developers/1pass...
I know that browser extensions are in general a pretty terrible ecosystem in terms of security, but am I off-base for thinking this is not a great look for 1password? Maybe I'm just underestimating how hard this is to solve generally, but my expectation would be that it shouldn't be that hard to keep track of which circumstances you're loading entire external scripts to manipulate the DOM and not do it accidentally in places you have no need for it.
Re: Why is calling my asm function from Rust slower than calling it from C?
#4For example, before we had something like: top: *const FFISafe > We can change that to: top: WithOffset > rust, you were meant to replace c++, not join it...
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 type of thing is necessary in some places.
(To preempt any potential explanations about this: yes, I understand the reference being made with that quote. I just don't think it actually applies here at all)
Re: Why is calling my asm function from Rust slower than calling it from C?
#5For example, before we had something like: top: *const FFISafe > We can change that to: top: WithOffset > rust, you were meant to replace c++, not join it...
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.
Re: Why is calling my asm function from Rust slower than calling it from C?
#6Earlier 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.
To me it implies abstraction such as a constructor, but with no overhead compared to the same steps done in some other way.
Re: Why is calling my asm function from Rust slower than calling it from C?
#7Earlier 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.
To me it implies abstraction such as a constructor, but with no overhead compared to the same steps done in some other way.
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.
Re: Why is calling my asm function from Rust slower than calling it from C?
#8Earlier 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.
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 the ecosystem might be able to infer this is likely a third-party library just from the fact that the capitalization is not in the typical format that official things use; if it were in std, I'd expect it to be FfiSafe, similar to how IoSlice[1], Arc[2], Shl[3], TypeId[4] etc. don't treat separate parts of an abbreviation/acronym/initialism as word breaks).
[1]: https://doc.rust-lang.org/std/io/struct.IoSlice.html [2]: https://doc.rust-lang.org/std/sync/struct.Arc.html [3]: https://doc.rust-lang.org/std/ops/trait.Shl.html [4]: https://doc.rust-lang.org/std/any/struct.TypeId.html
Re: Why is calling my asm function from Rust slower than calling it from C?
#9Earlier quoted context omitted.
To me it implies abstraction such as a constructor, but with no overhead compared to the same steps done in some other way.
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).
Re: Why is calling my asm function from Rust slower than calling it from C?
#10Earlier 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.
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 the puff pieces on the language, I don't think I'm alone in this belief of what the average Rustacean holds to be true.
> I'm not sure how you could avoid having external libraries ever implement an abstraction with a cost.
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.
Yes, we all know that abstractions sometimes obscure what is really going on, but the tradeoff is that the code is shorter and prettier, and easier to understand at a higher level. That's... not what is going on here.