Wait, you're telling me that this whole time, the most basic compiler feature of parallel compilation was missing from Rust, yet they wanted this shit in the Linux kernel?
If you still have to ask, the answer is NO.
also FUCK OFF.
>easter compilation
You do realize that with parallel compilation, when you compile a program, your whole OS will freeze right? Cargo, rustc always uses 100% of the CPU core it is given. This just means more crashes and freezes
>Below Normal priority (renice for linux troons) >or just N-1 threads >or not using Wayland which somehow still has no hardware cursor
Nothing personal, homosexual.
>the most basic compiler feature of parallel compilation was missing from Rust
No C compiler parallelizes the frontend. It's not possible because C needs to be evaluated from "top to bottom", the order of evaluation matters.
>Can't you just resolve everything in a quick early stage and parallelize the intensive work?
Probably not worth it for C, the language was made to be easy to parse on a PDP-11. C++ would benefit a lot (try doing a unity build of Chromium or Firefox if you don't believe me).
Saying is _in_ the kernel is a bit of an overstatement. Support for writing modules in Rust is in the kernel, but there isn't a single one in the main tree right now
>retard with no clue about compiler design posts inane comment about compiler design
embarrassing
retard
> Doesn't know what a compiler front-end is
Embarassing
seething rust tranny
https://i.imgur.com/2yejv2r.png
Did they just fix slow compile times?
https://blog.rust-lang.org/2023/11/09/parallel-rustc.html
>The nightly compiler is now shipping with the parallel front-end enabled. However, by default it runs in single-threaded mode and won't reduce compile times. >nightly
two more weeks.
> When the parallel front-end is run in multi-threaded mode with -Z threads=8, our measurements on real-world code show that compile times can be reduced by up to 50%, though the effects vary widely and depend on the characteristics of the code and its build configuration. For example, dev builds are likely to see bigger improvements than release builds because release builds usually spend more time doing optimizations in the back-end.
Sounds dope.
It already went wrong at the moment you have a package manager for a language. Just see all the shit that has happened with npm. Anyone writing important shit knows not to use it
This sort of fine-grained parallelism can be really hard and it doesn't seem like any of the big three C++ compilers have it. Coarser parallelism is normal but rustc already had that
Wait, you're telling me that this whole time, the most basic compiler feature of parallel compilation was missing from Rust, yet they wanted this shit in the Linux kernel?
You do realize that with parallel compilation, when you compile a program, your whole OS will freeze right? Cargo, rustc always uses 100% of the CPU core it is given. This just means more crashes and freezes
>Below Normal priority (renice for linux troons)
>or just N-1 threads
>or not using Wayland which somehow still has no hardware cursor
Nothing personal, homosexual.
I already has several forms of parallelization. They just parallelized another part.
>retard with no clue about compiler design posts inane comment about compiler design
embarrassing
Parallelizing the compiler is literally rule #1 of writing a compiler, it's the first thing you do when you start making one
Bruh, most compilers out there are not parallelized. And no, running many gccs/clangs at the same time on different translation units does not count
Wait, you're telling me that this whole time, the most basic human ability to read was missing from cniles, yet they still think they matter?
If you already know how to program, why would you read?
>the most basic compiler feature of parallel compilation was missing from Rust
No C compiler parallelizes the frontend. It's not possible because C needs to be evaluated from "top to bottom", the order of evaluation matters.
Can't you just resolve everything in a quick early stage and parallelize the intensive work?
They're still working on it thoughever
https://gcc.gnu.org/wiki/ParallelGcc
>Can't you just resolve everything in a quick early stage and parallelize the intensive work?
Probably not worth it for C, the language was made to be easy to parse on a PDP-11. C++ would benefit a lot (try doing a unity build of Chromium or Firefox if you don't believe me).
>they wanted this shit in the Linux kernel?
It is already in the Linux kernel, isn't it?
The shills made a kernel module and called it a victory, you have to add it manually or it doesn't even get compiled
Saying is _in_ the kernel is a bit of an overstatement. Support for writing modules in Rust is in the kernel, but there isn't a single one in the main tree right now
> Doesn't know what a compiler front-end is
Embarassing
If you still have to ask, the answer is NO.
also FUCK OFF.
chad
retard
seething rust tranny
>The nightly compiler is now shipping with the parallel front-end enabled. However, by default it runs in single-threaded mode and won't reduce compile times.
>nightly
two more weeks.
rust releases a new version every 4 weeks
retard
>easter compilation
> When the parallel front-end is run in multi-threaded mode with -Z threads=8, our measurements on real-world code show that compile times can be reduced by up to 50%, though the effects vary widely and depend on the characteristics of the code and its build configuration. For example, dev builds are likely to see bigger improvements than release builds because release builds usually spend more time doing optimizations in the back-end.
Sounds dope.
>throw 8x parallelism at it
>only get 2x performance improvement
uhhhh, fearless concurrency bros?
Look at the flame graphs and there's obviously a lot of computation that's still single threaded
Don't care, still setting codegen-units=1, -j1 and -Z threads=1.
https://rust-lang.github.io/rfcs/3463-crates-io-policy-update.html
this is a way more important rust development unironically
It already went wrong at the moment you have a package manager for a language. Just see all the shit that has happened with npm. Anyone writing important shit knows not to use it
>we speed it up by using more resources
absolutely laughable. this is in no way a performance increase
If I have to wait less long it's good enough for me
So it has nothing to do with Rust but with hardware.
>Guys we fixed compiling times, here is what you need to do: buy better CPU.
Fucking hacks.
?
I just don't see how this is big achievement, it should be there by default.
This sort of fine-grained parallelism can be really hard and it doesn't seem like any of the big three C++ compilers have it. Coarser parallelism is normal but rustc already had that