Hacker News Reader

Comment by tomrod | Hacker News Reader

Why not Rust? I am in a similar situation to the author. Python handles most of what I need, but that last 20% I need more.

View on HN

The Rust compiler is well known for having rather less-than-stellar performance, and this can definitely impact larger projects. (Much of the problem is not quite related to Rust itself, but rather to the intermediate compilation artifacts that are fed to LLVM for final code generation. It's not exactly an easy issue to address, given that LLVM itself is rather old and clunky code; written in C++ for maximum portability, not so much performance.)

> The Rust compiler is well known for having rather less-than-stellar performance.

You can do 'cargo check' to do the analysis part without actually compiling a binary, it's super fast and excellent for development.

> Much of the problem is not quite related to Rust itself, but rather to the intermediate compilation artifacts that are fed to LLVM for final code generation.

Considering clang generates LLVM IR and compiles much more quickly than Rust, this argument doesn't hold. The Rust compiler generates IR which chokes LLVM and makes it slow, but they didn't have to do that.

Yes and no; we can reduce the amount of it, but since we have different features, we will pretty much inherently generate code that skips FastISel. For example, “match” generates IR that’s not part of it. (See here for more: https://internals.rust-lang.org/t/why-cant-rust-use-llvm-fas...)

It’s a huge problem with a number of different causes.

> Yes and no;

Steve, this is a cop out. There's nothing in Rust that can't be implemented in C or any other Turing complete language, including stack unwinding, invoke, or anything else. It may be inconvenient for Rust to use or not-use some feature of LLVM, but that's not the same thing.

Turing-completeness is – as always – a red herring.

Sure, I can technically use Assembler to write a modern Windows program, but that's no argument against high-level languages.

I think you mean well with this comment, but you're thinking about it incorrectly. Imagine that it's possible to implement these features in the FastISel subset; okay, we do that. Now, we're generating way more code. So we're back to square one.

Being able to implement something does not mean that by implementing it a different way, it will certainly be faster. And that's what we're talking about here, compilation speed, not computational equivalence.

We find tons of bugs in LLVM due to using certain features (like noalias) that are used a lot by Rust and very, very little by current C or C++ codebases. That shouldn't be particularly surprising. Nor should it be surprising that LLVM is mostly optimized for making C and C++ compilation times fast, and not necessarily other languages.

Again, as I said, it's a complex, multi-faceted problem. You can't just say "well, Zig compiles to LLVM, and it compiles fast, checkmate." That's not how engineering works.

(And, note that FastISel is "This is a fast-path instruction selection class that generates poor code and doesn't support illegal types or non-trivial lowering, but runs quickly." So, the thing I'm talking about is a thing that would help debug build times, but not production build times. I'm not claiming that this one specific thing is the root cause of poor compile times, in fact, I'm claiming the opposite: there are a number of different things that all come together to lead to compile times being not as fast as we'd like.)

What feature of Rust requires elaborate features or massive amounts of code? C++ has stack unwinding, you can implemented dynamic dispatch in C with function pointers, and Rust's match isn't that much above a switch statement. Both C and C++ on top of LLVM compile much more quickly than Rust.

You added to your comment while I was replying, so adding to what I said in the sibling reply:

> Being able to implement something does not mean that by implementing it a different way, it will certainly be faster.

Of course not, but if I point to implementing something which is equivalent but faster, you can't say it's impossible to do it fast any more.

> You can't just say "well, Zig compiles to LLVM, and it compiles fast, checkmate." That's not how engineering works.

Yeah, actually I can. The claim is that LLVM is slow, so it's not Rust's fault. But LLVM isn't slow when compiling a language with nearly equivalent features, so that's a poor excuse. That's how engineering, logic, and accountability work. There is nothing in Rust which doesn't have an analog in C++, and C++ compilers aren't as slow as the Rust compiler.

> note that FastISel is "This is a fast-path instruction selection class that generates poor code and doesn't support illegal types or non-trivial lowering, but runs quickly."

You brought FastISel into the discussion. This is just another part of the shell game. Compare clang++, g++, and rustc with optimizations on or off.

> The claim is that LLVM is slow, so it's not Rust's fault.

I never claimed this. I claimed that there are a number of interlocking issues that make Rust compilation slow, and pointed out one that I haven’t seen a ton of discussion about before as an example of how it’s not a simple problem.

I also started this conversation by acknowledging one of the things that you said, which was that we generate a lot of LLVM-IR. That’s one that does get talked about a lot.

I don’t think we’re really gonna make any progress here so I’ll leave it at that.

> I never claimed this.

No, the person I first replied to did. Then you jumped in and defended his position with your "yes and no" comment.

> I don’t think we’re really gonna make any progress here so I’ll leave it at that.

I agree. I always appreciate your friendliness and thoughtfulness, but I've never gotten you or anyone else on the Rust team to budge an inch on the problems with Rust. (which is a shame, because it's close to being a great language...)

I was replying to just you, not defending them.

It seems we’re in full agreement about the problems: compile times are too slow! Everyone acknowledges this. It seems like our disagreement is about the why.

"And that's what we're talking about here, compilation speed, not computational equivalence."

I believe the original poster meant generated code when (s)he wrote about compiler performance; the compile time is rather irrelevant for something that gets done once; what's relevant is the speed of the generated code which then runs the next billion times (or more).

So let's get back to the performance of the code generated by the Rust compiler, shall we?

That performance is mostly really good at the moment. There's some things to do, but we're already roughly at the same place C and C++ are.

...Which means you have lots of ground to cover before you reach parity with Fortran (phase 1), and then reach parity with CUDA Fortran (phase 2).

You're working from old information. Show me a benchmark where Fortran wins over C or C++ any more. Those days are gone. Here's my line in the sand:

    https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/fortran.html

As for GPUs, no contest.

Benchmarks are meaningless. I know from experience at looking at the generated assembler code and intel Fortran's SIMD code that it's faster. Take a look at the generated code and then we can discuss it, but not before.

I'm not going to beat myself in C when I calculate a 100 million by 100 million matrix in Fortran. ifort will generate SIMD code with CPU autodetection and use machine code seqencing best for that processor, plus in Fortran a matrix is a normal variable type like any other. I'm not beating that with C (and I really know C).

And just so you know, my information isn't old, I come from supercomputing.

> Benchmarks are meaningless.

Random anecdotes are meaningless. I've looked at plenty of generated code, and I've written plenty of SIMD assembly too. If you can't measure it, you can't compare it or improve it. There's nothing to discuss.

So if you looked at it, where are the assembler listings to compare? Let me see, I want to see too!

If there is nothing to discuss and you plain refuse to do what I told you, why reply? Until you do exactly what I told you, there is nothing to see here. I have zero tolerance for people who won't listen. Move along, move along.

It's very weird you have the presentation of an impudent 20 year old but you share an irrational preference for Fortran, which is something I'm only used to seeing in people who are past their mid 50s.

"Move along"? You're very full of yourself, and I think that explains why you aren't as smart as you think you are.

What you are or aren't used to seeing is about relevant to me as the last year's snow. You're free to think whatever the hell you want, that being a basic human right. Move along now, nothing to see here.

If you can contribute better Fortran programs for those Intel Fortran measurements, please do.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

https://salsa.debian.org/benchmarksgame-team/benchmarksgame/...

And who will compensate me for my free time spent on that and at which rate per hour in USD?

Where and to whom do I send the bill?

If you don't wish to contribute better Fortran programs for those Intel Fortran measurements, then don't.

Where does it say that I don't wish to contribute? I asked about pay because my free time isn't worthless to me and I got back a tangential answer. "Hacker" "News" at its finest.

Seems like you wish to quarrel with someone about something.

If you wish to contribute then please follow the instructions; if you don't wish to contribute then have a nice day.

I note how you consistently avoid to discuss monetary compensation for investing my time into contributing. Yeah it pisses me off that you believe my free time is worthless and that you're just entitled to ask someone to donate their time without providing anything in return.

To know the price of everything but the value of nothing.

My free time is the most precious, most treasured, dearest thing I have ever had.

If Rust didn't have good runtime performance, it wouldn't be worth looking at over SML, Ocaml, or Haskell.

> So let's get back to the performance of the code generated by the Rust compiler, shall we?

"Shall we" just stick our heads in the sand too? No, you don't fix problems by ignoring them or pretending they aren't a problem. Slow compilation speed is a problem if you care about developer productivity and quality of life.

Slow compilation speed is never a problem, I doubt anyone besides you cares about it. What is important is whether it generates fast code. Taking a long time to compile is fine if I get very fast code. I'm not going to be compiling code anywhere near as many times as I'm going to be running it.

You really think it's just me? Take care.

I do. Computers for most people are tools to perform final work faster, not a purpose unto itself which is all about programmer's convenience. A programmer's job is to be as uncomfortable and to suffer as much as possible so that the users could suffer as little as possible or not at all. This "developer convenience" attitude should be reproached or even financially penalized, so that such prima donnas finally come down to earth and start taking responsibility for their (shitty) software.

Compilers don't have to be slow to generate good code (at least not as slow as Rust). If you prefer them slow, you're just choosing to be ineffective like some idiotic martyr. Suffering for it's own sake is just stupid.

I don't care about that, could not care less: I just do make -j 96 and go do something else. The only thing that matters is very fast code. Back-end optimizers cost CPU cycles, there's no way around that. Expecting fast compilation times when iropt and lto have to do their thing is incredibly naive. How can anyone in this day and age be so naive?

Reply on news.ycombinator.com