Rust Performance Is Getting Hurt On LLVM 10 With Noticeably Longer Build Times

[JustinTurdeau]

Of course LLVM IR has to be good. I was just saying, there's no technical reason Rust can't be as fast as C/C++.
Unless you think for some reason Rust is incapable of outputting proper LLVM IR.

It doesn't matter what "is possible" or why there is "no technical reason" something couldn't hypothetically be done. That's just the age-old "sufficiently smart compiler" fallacy. All that matters is what it actually does produce in reality.

Do you really think a layman like yourself trotting out trite and meaningless platitudes like this offers any value or insight whatsoever...?

[Almindor]

This is just handwaving and wishful thinking.

Saying "hurrr, it generates LLVM IR so it should be fast" is brainlet-tier logic. The generated IR still has to be good. Just because you don't understand it and think of it as a magic black box, doesn't mean all generated LLVM IR is equivalent and equally fast. It can be worlds apart.

Rust is already outperforming C/C++ even in 100% safe code which is an achievement most of you trolls wouldn't consider possible.

The aliasing issue is an old LLVM problem that is known and will in some cases produce a nice boost to performance. It's also a really good example where the language level impact performance due to this only being possible when the type/pointer/reference system supports it. In other words Rust can produce more informed IR for LLVM here than C/C++ because it has more information about the problem domain.

[bug77]

It doesn't matter what "is possible" or why there is "no technical reason" something couldn't hypothetically be done. That's just the age-old "sufficiently smart compiler" fallacy. All that matters is what it actually does produce in reality.

Do you really think a layman like yourself trotting out trite and meaningless platitudes like this offers any value or insight whatsoever...?

And what does it produce in reality? Please enlighten me.

Thanks for the name calling, that always raises the bar in a conversation.

[JustinTurdeau]

Rust is already outperforming C/C++ even in 100% safe code

More claims with zero evidence. Rust is not even close to outperforming C.

[JustinTurdeau]

And what does it produce in reality? Please enlighten me.

Thanks for the name calling, that always raises the bar in a conversation.

For anything other than cherry-picked micro-benchmarks, rustc produces significantly worse code than gcc. But don't let facts or reality get in the way of some good evangelism.

[Almindor]

For anything other than cherry-picked micro-benchmarks, rustc produces significantly worse code than gcc. But don't let facts or reality get in the way of some good evangelism.

And the proof of your statement is?

[smitty3268]

For anything other than cherry-picked micro-benchmarks, rustc produces significantly worse code than gcc.

Can you point out something that's not a cherry-picked micro benchmark that shows this? Everything I've seen generally has Rust within 5% of C/C++, and massively ahead of any 4th place languages behind it.

[JustinTurdeau]

And the proof of your statement is?

The burden of proof should be on the person making the original claims, not the person refuting them. So where's your proof...? I'll wait.

[JustinTurdeau]

Can you point out something that's not a cherry-picked micro benchmark that shows this? Everything I've seen generally has Rust within 5% of C/C++, and massively ahead of any 4th place languages behind it.

See, that's where people go wrong. The 4th place languages are utterly irrelevant and should be cast out of the picture entirely.

People are thinking "oh look, Rust is just behind C and all the other languages are a factor of 10 behind -- ergo Rust is basically as fast as C". That's just human perception distorting your idea of how far behind it is. In the benchmarks I've seen, Rust often lags 10-30% behind C in speed, while using twice the memory. That's huge. The fact that Python is 20x slower doesn't matter at all.

So either someone will link to a definitive article, wherein the author demonstrates beyond any doubt that code generated by rustc is comparable in performance to that generated by GCC.....or it just isn't. It's as simple as that. These contortions and whataboutisms and "no-reason-why-not-isms" that are so rife in the Rust community are so tiresome...

[LuukD]

Justin, have you tried Rust? What is it you particularly dislike about it?
Judging your demeanor I might not be able to convince you Rust is anything else than 'vaporware', but for what its worth, the Debian project hosts 'the benchmariking game', an ongoing effort to see which language is best performing in its best effort implementation on a given problem'. All critiques and marginal notes on benchmarks apply, however the general gist one gets from reading these results is there are three top contenders C / C++ and Rust. [ https://benchmarksgame-team.pages.de...test/rust.html ]

I like the fact that everything in Rust is an expression which allows for

let (a, b) = { .. expression that yields the tuple }

, I like the functional programming features which let you write

str_b = str_a.split_whitespace().filter(|c| c != "Phoronix" ).collect();

'match' and pattern matching can do many things. I love cargo and the crates system; how you define dependencies and link against 'em is a breeze compared to Makefiles and pkgconfig. Cargo finds what I need, retrieves it, builds and links it like magic.
I sometimes get confused because iterators behave less unified than I expect (ie. some consume, some don't, some return Options<T> some values) and I think some signatures are downright intimidating, eg. when functions are bound by some compounded explicit lifetimes plus some traits with their own peculiar bounds, but maybe thats just me - and macros can hamper readability because they hide what is really happening and I would have liked for types and traits to be distinguishable by syntax convention, because both are now CamelCase.

Don't get me wrong, C is cool and seasoned C programmers are perhaps even cooler, but I rather get corrected at compile time than having to stare at segfault wondering what could possibly have gone wrong now.