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

[jacob]

No immutability. No type-checking. No switch statements. Function-level scoping. A standard library crammed full of stuff that only sorta works. Memory usage. Exceptions.

These are features, not bugs, while doing the exact opposite of Python's design choices is also a feature, not a bug. I would say Python is a superb language for its intended application areas and the only grudge I hold against it is its pathetically crippled lambda syntax. For problems that are best solved using a statically typed language, or immutability, there is Rust, Haskell etc. Use the right tool for the job: attempts to create the "definitive" language that would be all things to everyone has always resulted in monstrosities like Ada or C++.

[wizard69]

Build times are not a performance issue all on their own! The real question is this; does the new compiler build faster executables or otherwise improve the end product.

[wizard69]

I read that 9 years ago when Rust was first released, I'll read that 9 years from now.
I'm not terribly fond of its syntax, but the idea behind it is something that will be a must in system-programming languages to come. And while I don't use it much, simply thinking about implementing something in Rust will help you avoid some design issues.

To get the serious usage that it needs, Rust needs to be codified by a standards body. The fact that there are ANSI/ISO standards for C & C++ has keep those languages viable far longer than maybe they should have survived. Rust will stay around but I can't see serious users doing anymore than playing with it for now.

[LuukD]

>llvm
>rust
Both bloat and slow crap.

Nonono. that acronym is spelt 'crab', correct, readable and blazingly fast!

Jokes aside, there has indeed been a regression in '--release' builds, less so in debug builds.
Work on compiler performance is ongoing: https://blog.mozilla.org/nnethercote/2020/04/24/how-to-speed-up-the-rust-compiler-in-2020/

Originally posted by Raka555 View Post

Maybe the rust people will rewrite it in rust ...

(I will actually cheer for them this time, if they do)

You may want to dust your pom poms because the the 'cranelift' backend to speed up development builds is high on the agenda: https://github.com/rust-lang/compiler-team/issues/257

[flashmozzg]

To get the serious usage that it needs, Rust needs to be codified by a standards body. The fact that there are ANSI/ISO standards for C & C++ has keep those languages viable far longer than maybe they should have survived. Rust will stay around but I can't see serious users doing anymore than playing with it for now.

That's laughingly incorrect.
JS, C and C++ are probably the only languages that are still widely (i.e. not in some niche industry) used with the new projects (and not just legacy maintenance) with the actual ISO standard (and language development centered around ISO processes).

[bug77]

To get the serious usage that it needs, Rust needs to be codified by a standards body. The fact that there are ANSI/ISO standards for C & C++ has keep those languages viable far longer than maybe they should have survived. Rust will stay around but I can't see serious users doing anymore than playing with it for now.

You seem to assume there's some usage Rust needs
Rust, like any other language, is a tool. It will be a good choice for the problem you're trying to solve or it won't. As long as there's a class of problems Rust solves easier than any other language, Rust will see usage.

[JustinTurdeau]

Sadly LLVM devs have a tendency to ignore issues related to only Rust (see years old aliasing bugs in LLVM that'd make Rust outperform even C in some cases).

You Rustbots can never pass up an opportunity to tell people how Rust could, in theory, be faster than C.

The best thing about vapor-features is that you get a sweet marketing boost without actually delivering anything...

[bug77]

You Rustbots can never pass up an opportunity to tell people how Rust could, in theory, be faster than C.

The best thing about vapor-features is that you get a sweet marketing boost without actually delivering anything...

I'm not sure why you think performance is an issue with Rust. Rust produces LLVM IR (and prides itself for zero-cost abstractions). From there on, any code generated should perform exactly the same.
All that was said is that there is at least one LLVM bug that prevents that from happening.

[JustinTurdeau]

I'm not why you think performance is an issue with Rust. Rust produces LLVM IR (and prides itself for zero-cost abstractions). From there on, any code generated should perform exactly the same.
All that was said is that there is at least one LLVM bug that prevents that from happening.

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.

[bug77]

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.

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.