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

Performance of Rust Language [pdf]

github.com

Post reply on HN
Print view View original

61–70 of 146 posts

Re: Performance of Rust Language [pdf]

#61

Post by tialaramex »

jandrewrogers wrote: post #7

I would summarize it thusly: Rust is roughly as performant as C. This matches my experience and Rust is more ergonomic than C in many regards. The caveat is that modern C++ is notably more performant than C and by implication Rust. This also matches my experience for both C and Rust. I think most of this is attributable to the ergonomics of compile-time expressiveness. C++ can effortlessly do things that require moun…

You say you are "summarizing" something but instead you seem to have just injected your opinion that C++ is "notably more performant than C and by implication Rust".

It's true that you can express many things in C++ -- the problem is that the language deliberately doesn't distinguish whether the things you've expressed are nonsense, so you might well have written total nonsense and you only find out when, much later, diagnosing a real world event you discover oh, this is nonsense, why did this even compile? Well sorry, it was "more performant" to allow nonsense.

Re: Performance of Rust Language [pdf]

#62

Post by edevrk »

nicoburns wrote: post #60
edevrk wrote: post #52

Earlier quoted context omitted.

[flagged]

A little slower but safe is a pretty good default I think. Most of the time you're not in a hot loop and even a 5% slowdown would be negligable. And in the cases where you are in a hot loop you just have to put in a little extra effort to optimise it and gain the performance back, either by writing the code in a way that allows the compiler to prove correctness (e.g. using an iterator or assert), or by using the unsa…

[flagged]

Re: Performance of Rust Language [pdf]

#63

Post by nicoburns »

edevrk wrote: post #62
nicoburns wrote: post #60

Earlier quoted context omitted.

A little slower but safe is a pretty good default I think. Most of the time you're not in a hot loop and even a 5% slowdown would be negligable. And in the cases where you are in a hot loop you just have to put in a little extra effort to optimise it and gain the performance back, either by writing the code in a way that allows the compiler to prove correctness (e.g. using an iterator or assert), or by using the unsa…

[flagged]

> Did you generate your comment using LLM?

(It was hand written. Typos and all.)

Re: Performance of Rust Language [pdf]

#64

Post by afdbcreid »

elcritch wrote: post #44
jandrewrogers wrote: post #7

I would summarize it thusly: Rust is roughly as performant as C. This matches my experience and Rust is more ergonomic than C in many regards. The caveat is that modern C++ is notably more performant than C and by implication Rust. This also matches my experience for both C and Rust. I think most of this is attributable to the ergonomics of compile-time expressiveness. C++ can effortlessly do things that require moun…

Nim also has top notch meta programming, probably more so than Zig. You can easily do loop unrolling, specialization, etc. For example Constantine, which is a constant time crypto library that outperforms C, etc. To me programming Rust feels so limiting due to lack of good compile time meta programming with types . That’s the key.

How can you create constant-time code with Nim when none of its backends support it (e.g. LLVM may turn an apparently-constant-time code into non-constant-time assembly)?

Re: Performance of Rust Language [pdf]

#65

Post by afdbcreid »

nsajko wrote: post #58
jandrewrogers wrote: post #7

I would summarize it thusly: Rust is roughly as performant as C. This matches my experience and Rust is more ergonomic than C in many regards. The caveat is that modern C++ is notably more performant than C and by implication Rust. This also matches my experience for both C and Rust. I think most of this is attributable to the ergonomics of compile-time expressiveness. C++ can effortlessly do things that require moun…

Julia is another contender. Julia code can be as performant as C++ code, but Julia code may be even more elegant than C++. Even without accounting for Julia's metaprogramming features, the compile-time expressiveness is top-notch. It shares some of the same drawbacks as C++, though. The language is extremely powerful, so while it is easy to write performant code, it is also easy for non experts to write very suboptim…

Julia is not a systems language. Also its design (GC, dynamic typing) does not allow it to reach exactly the same level as C++.

Re: Performance of Rust Language [pdf]

#66

Post by zozbot234 »

edevrk wrote: post #52
simonask wrote: post #37

Earlier quoted context omitted.

Panics in Rust do not currently time-travel like that (including panics from failed bounds checks), and that's a good thing. The reason is that panicking does not imply terminating the process - they can be caught and handled, just like exceptions in C++. In fact, they use the same stack unwinding mechanism by default. What the compiler is allowed to do is to shorten the loop by one and unconditionally panic after th…

[flagged]

If you can detect a case where a panic "time traveling" would meaningfully improve performance, you could simply let the compiler issue an optional warning that would allow for auto-fixing the code to have those different semantics.

Re: Performance of Rust Language [pdf]

#67

Post by afdbcreid »

simonask wrote: post #37
Animats wrote: post #5

There's a discussion of "delayed bounds checking", but not "hoisted bounds checking", where bounds checking is done early. Consider let mut tab: [usize;100] = [0;100]; ... for i in 0..101 { tab[i] = i; } This must panic at i=100. Panic becomes inevitable at entry to the loop. Is the compiler entitled to generate a check that will panic at loop entry? The slides suggest that Rust does not hoist such checks, and, so, w…

Panics in Rust do not currently time-travel like that (including panics from failed bounds checks), and that's a good thing. The reason is that panicking does not imply terminating the process - they can be caught and handled, just like exceptions in C++. In fact, they use the same stack unwinding mechanism by default. What the compiler is allowed to do is to shorten the loop by one and unconditionally panic after th…

It's true that panics (unlike UB) cannot automatically time-travel, but your justification is weak. Recovering from panics can only prevent this optimization if the loop have side effects, and LLVM knows when panic=abort is set.

Re: Performance of Rust Language [pdf]

#68

Post by rirze »

afdbcreid wrote: post #65
nsajko wrote: post #58

Earlier quoted context omitted.

Julia is another contender. Julia code can be as performant as C++ code, but Julia code may be even more elegant than C++. Even without accounting for Julia's metaprogramming features, the compile-time expressiveness is top-notch. It shares some of the same drawbacks as C++, though. The language is extremely powerful, so while it is easy to write performant code, it is also easy for non experts to write very suboptim…

Julia is not a systems language. Also its design (GC, dynamic typing) does not allow it to reach exactly the same level as C++.

Julia only cares about numerical performance, and in that regime, it’s pretty fast.

So not generally fast, no.

Re: Performance of Rust Language [pdf]

#69

Post by tialaramex »

nicoburns wrote: post #56
loeg wrote: post #11

Earlier quoted context omitted.

C++ you get templated generic algorithms that in practice no one really does with C because macros suck too much. So in C typically you'd have a runtime generic routine that doesn't inline. A classic example here is qsort() vs std::sort().

Rust also has these advantages of course

Indeed Rust's standard library provides much better sorts both in terms of performance and in terms of resistance to abuse than those provided in the big three C++ implementations.

Re: Performance of Rust Language [pdf]

#70

Post by santiagolertora »

Animats wrote: post #5

There's a discussion of "delayed bounds checking", but not "hoisted bounds checking", where bounds checking is done early. Consider let mut tab: [usize;100] = [0;100]; ... for i in 0..101 { tab[i] = i; } This must panic at i=100. Panic becomes inevitable at entry to the loop. Is the compiler entitled to generate a check that will panic at loop entry? The slides suggest that Rust does not hoist such checks, and, so, w…

[dead]
Post reply on HN