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.
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.)
> 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.
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.
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...)
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.
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?
https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/fortran.html
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.
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.
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.
"Move along"? You're very full of yourself, and I think that explains why you aren't as smart as you think you are.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
https://salsa.debian.org/benchmarksgame-team/benchmarksgame/...
Where and to whom do I send the bill?
If you wish to contribute then please follow the instructions; if you don't wish to contribute then have a nice day.
> 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.
Sure, I can technically use Assembler to write a modern Windows program, but that's no argument against high-level languages.