Earlier quoted context omitted.
Probably yes, the LLVM linker is really slow
Rust is only using LLD on ARM targets.
It's used on wasm as well.
The Rust compiler is still getting faster
71–80 of 100 posts
Re: The Rust compiler is still getting faster
#72Maybe they should make compiling the Rust compiler faster. Right now it takes longer and uses more CPU and memory than compiling a whole LLVM toolchain, then using that toolchain to compile a whole kernel and OS.
Re: The Rust compiler is still getting faster
#73Earlier quoted context omitted.
> ... the ability to refactor large-scale software without breaking anything ... and no low-level programming language except for Rust has it. Ada has had the same characteristics since '83. Thanks to strict typing (among other features), Ada programmers have enjoyed "safe" code refactoring for decades. But it is nice that new languages like Rust are finally picking similar ideas and design choices.
Ada languished for years with expensive, proprietary compilers and a community that largely ignored open source culture. Is it any surprise that Rust is having more success breaking into the modern mainstream software world?
I fail to see how your parent implied surprise.
Re: The Rust compiler is still getting faster
#74Faster compiler is nice, but you know what's faster? Not having to compile anything. I'm also looking forward to crates.io serving precompiled crates ( https://www.ncameron.org/blog/cargo-in-2019/ )
I'm a Rust noob but I think skunkopalypse was making some good points. I wish people didn't vote down his/her comment to death and actually replied to it so I could learn why he/she wasn't right.
I too think that precompiling crates won't really solve the problem.
If you compare the compiled artifact (rlib) of a crate with the source code, you'll quickly see that the compiled artifact is much larger than the source code. libglutin-0c732c31a1d003fb.rlib has 8.1 MB while glutin-0.22.0-alpha1.crate has 53 KB.
Most people have shitty internet. And often it's nothing you can do about it because you have shitty ISPs. You can buy a computer with good CPUs and those are usually cheaper in comparison than good internet for a year, at least in many rural areas in the US. It's not just the US, some other countries have it even worse.
Now of course if you have good internet and a bad CPU it's a good deal, so there should definitely be an option to use it, maybe even with autodetection. But I think cargo has too much dependency on the internet, not too little. There should be no manual input required to turn off precompiled crates downloads if it is faster to compile the crates locally.
Re: The Rust compiler is still getting faster
#751. make a really slow compiler 2. slightly improve it over time 3. write blogs about it 4. win? How about releasing software with reasonable performance in the first place? This was just discussed yesterday that everyone prefers faster software.
Gee, I wonder why the developers of a very complex, high performance browser and now also of a low level systems language with the following motto: "A language empowering everyone to build reliable and efficient software." didn't think of that!
They probably just forgot to un-comment
// let compileSpeed = fast;
in src/compiler/main.rs
Their resources were limited and they chose to focus on more important things at the time. Now they're focusing on compilation speed. And those more important things Rust offers aren't really offered by any other mainstream language.
Re: The Rust compiler is still getting faster
#761. make a really slow compiler 2. slightly improve it over time 3. write blogs about it 4. win? How about releasing software with reasonable performance in the first place? This was just discussed yesterday that everyone prefers faster software.
For most software I would agree with you. Usually you have some CRUD application where people don't know how to index and use hashing. But the Rust compiler is an amazing static analyzer. Running one on C++ to get the same level of memory safety will often take hours on sizeable projects.
A static analyzer which requires correct code to be rewritten in a certain way to satisfy the analyzer does not deserve to be called amazing.
Re: The Rust compiler is still getting faster
#77Earlier quoted context omitted.
For most software I would agree with you. Usually you have some CRUD application where people don't know how to index and use hashing. But the Rust compiler is an amazing static analyzer. Running one on C++ to get the same level of memory safety will often take hours on sizeable projects.
A static analyzer which requires correct code to be rewritten in a certain way to satisfy the analyzer does not deserve to be called amazing.
Don't all static analyzers do that? Or they're just ignored, which happened in almost every large project I've ever seen.
Re: The Rust compiler is still getting faster
#78Maybe they should make compiling the Rust compiler faster. Right now it takes longer and uses more CPU and memory than compiling a whole LLVM toolchain, then using that toolchain to compile a whole kernel and OS.
Compiling the Rust compiler also requires compiling LLVM, so by definition it will always take longer than that.
Re: The Rust compiler is still getting faster
#79Earlier quoted context omitted.
> you don't want the stdlib allocating nodes; you want an intrusive data structure instead. Don't C++'s std::list and Rust's std::collections::LinkedList effectively implement the moral equivalent (insofar as memory layout is concerned) of an intrusive list, though?
Yes, but they hide the memory layout as an implementation detail, thus negating most advantages of an intrusive list. You can't call `std::list ::erase()` with a Node* , and you can't write a function that converts from Node* to `std::list ::iterator` in standard C++, even though it's really just a matter of subtracting a fixed number of bytes from the pointer value. So you instead need to store the `std::list ::iter…
There's boost::intrusive::list which IME actually works quite well. There is a node type which elements derive from or contain, so you can get an iterator from an element, as well as the other way round. To include an element in multiple lists, just aggregate the node type multiple times.
Re: The Rust compiler is still getting faster
#80I wish compiling the Rust compiler itself was faster. It literally takes days to compile on my old laptop.
It is! The article is about the performance of the compiler, not the machine code it generates.