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

Rust Performance Pitfalls

llogiq.github.io

Post reply on HN
Print view View original

31–40 of 112 posts

Re: Rust Performance Pitfalls

#31

Post by steveklabnik »

tormeh wrote: post #29
steveklabnik wrote: post #16

Earlier quoted context omitted.

We actually did have this once, but it wasn't really worth it, so it was removed. https://news.ycombinator.com/item?id=6940624 is the HN discussion, but it looks like the link might now be wrong? It was also a very, very long time ago, and so today's Rust might be different enough that those reasons don't apply any more.

The reason at that point vis that there weren't any practical benefits and that it was preferable to wait for a more general mechanism. The first claim is dubious, but I can empathize with second, as long as it doesn't become tacked on. Haskell can do cool optimizations that make it feel like magic sometimes.

In some ways, const fn reminds me of this.

Re: Rust Performance Pitfalls

#32

Post by [deleted] »

jcranmer wrote: post #18
flavio81 wrote: post #4

Earlier quoted context omitted.

Good question. That would mean chaining two statements together so "nopes" is not allocated as a symbol. But, with "let", the user is explicitly instructing the compiler to allocate a reference for "nopes", so i don't think the compiler would chain the statements. Unless it takes the task to checking that "nopes" is not used elsewhere.

The code is problematic, but not because of the let. Optimizations work basically on the as-if principle: they're free to execute code any way they like, but the results must be as if they followed your explicit instructions. Compilers need not, and usually do not, preserve references just because you gave them a name--if you've ever run gdb on optimized code, you'll note how many variables become " " (although that'…

[deleted]

Re: Rust Performance Pitfalls

#33

Post by infogulch »

steveklabnik wrote: post #28
infogulch wrote: post #24

Earlier quoted context omitted.

While technically true, a specific example helps the reader conceptualize what level of danger that means, when they don't already have a concrete understanding like you do. Recall that the breadth of experience for rust's userbase is much larger than e.g. C.

Oh yeah, I mean, I'm not saying I disagree with adding detail, I can just see the impulse to not, since anything you say may or may not be true.

me talking about rust's userbase

steveklabnik's profile: "Rust core team"

I'm guessing you know that a lot better than I do lol.

Re: Rust Performance Pitfalls

#34

Post by steveklabnik »

infogulch wrote: post #33
steveklabnik wrote: post #28

Earlier quoted context omitted.

Oh yeah, I mean, I'm not saying I disagree with adding detail, I can just see the impulse to not, since anything you say may or may not be true.

me talking about rust's userbase steveklabnik's profile: "Rust core team" I'm guessing you know that a lot better than I do lol.

It's all good! You're absolutely right, and it's easy to forget when you're inside a bubble.

Re: Rust Performance Pitfalls

#35

Post by rabidferret »

agwa wrote: post #13
kibwen wrote: post #10

Earlier quoted context omitted.

What sort of language beyond "absolutely sure", "require unsafe", and "break your code in surprising ways" would you recommend to make this warning stronger?

Explain what might happen, as I did in my comment. People are more likely to take heed of a warning if it's concrete.

"requires unsafe" already implies everything in your comment. `unsafe` literally means "this might violate memory safety"

Re: Rust Performance Pitfalls

#36

Post by Asooka »

firethief wrote: post #17
Anderkent wrote: post #11

Earlier quoted context omitted.

'break your code in surprising ways' is super vague. Saying 'may cause out of bounds memory access/writes should the input not be valid UTF-8' explicitly is probably more scary.

That's the kind of vagueness that should sound like a warning to anyone considering that approach.

To me "your code breaks in surprising ways" means something more like "the user sees gibberish/wrong results" and not "your program segfaults". Segfaulting is not actually a surprising result to me - I have seen it over and over on out of bounds access.

Re: Rust Performance Pitfalls

#37

Post by dom0 »

stcredzero wrote: post #15
kibwen wrote: post #9

Earlier quoted context omitted.

Not in the referentially-transparent sense. Most Rust functions meet almost all of the practical criteria for for purity (i.e. does not mutate global state (or otherwise any state that was not explicitly passed in to the function), does not do I/O), but that's only a comfort for the programmer's ability to reason about the code; this weakened notion of purity-by-default isn't enough to allow the typical optimizations…

but that's only a comfort for the programmer's ability to reason about the code A way to mark functions as pure for this purpose would be great! Especially if it's not as fraught as const in C++.

const does not imply pure. If applied to a member function, it makes this const; if applied to types it makes types const. Purity is a different concept. The closest match would probably be constexpr.

Re: Rust Performance Pitfalls

#38

Post by kbenson »

rabidferret wrote: post #35
agwa wrote: post #13

Earlier quoted context omitted.

Explain what might happen, as I did in my comment. People are more likely to take heed of a warning if it's concrete.

"requires unsafe" already implies everything in your comment. `unsafe` literally means "this might violate memory safety"

No, I don't believe it does. There are perfectly safe operations that must be done in unsafe, because the compiler is not smart enough to determine they are safe. Thus when describing a potential operation, saying it "requires unsafe" does not imply it can blow up in your face, just that the compiler is not smart enough to determine that at this time.

This is exactly why warnings should strive to be as clear as possible. Just because you think it's not ambiguous, doesn't mean you aren't just missing some context that someone else might have that makes the statement somewhat ambiguous.

Re: Rust Performance Pitfalls

#39

Post by topspin »

kbenson wrote: post #38
rabidferret wrote: post #35

Earlier quoted context omitted.

"requires unsafe" already implies everything in your comment. `unsafe` literally means "this might violate memory safety"

No, I don't believe it does. There are perfectly safe operations that must be done in unsafe, because the compiler is not smart enough to determine they are safe. Thus when describing a potential operation, saying it "requires unsafe" does not imply it can blow up in your face, just that the compiler is not smart enough to determine that at this time. This is exactly why warnings should strive to be as clear as possi…

"saying it "requires unsafe" does not imply it can blow up in your face"

Good argument. If you advise someone to use unsafe the responsible thing to do is explain precisely what the consequences are besides "it's faster."

Post reply on HN