One big difference that Iโve noticed between Windows and Linux is that Windows does a much better job ensuring that the system stays responsive even under heavy load.
For instance, I often need to compile Rust code. Anyone who writes Rust knows that the Rust compiler is very good at using all your cores and all the CPU time it can get its hands on (which is good, you want it to compile as fast as possible after all). But that means that for a time while my Rust code is compiling, I will be maxing out all my CPU cores at 100% usage.
When this happens on Windows, Iโve never really noticed. I can use my web browser or my code editor just fine while the code compiles, so Iโve never really thought about it.
However, on Linux when all my cores reach 100%, I start to notice it. It seems like every window I have open starts to lag and I get stuttering as the programs struggle to get a little bit of CPU thatโs left. My web browser starts lagging with whole seconds of no response and my editor behaves the same. Even my KDE Plasma desktop environment starts lagging.
I suppose Windows must be doing something clever to somehow prioritize user-facing GUI applications even in the face of extreme CPU starvation, while Linux doesnโt seem to do a similar thing (or doesnโt do it as well).
Is this an inherent problem of Linux at the moment or can I do something to improve this? Iโm on Kubuntu 24.04 if it matters. Also, I donโt believe it is a memory or I/O problem as my memory is sitting at around 60% usage when it happens with 0% swap usage, while my CPU sits at basically 100% on all cores. Iโve also tried disabling swap and it doesnโt seem to make a difference.
EDIT: Tried nice -n +19, still lags my other programs.
EDIT 2: Tried installing the Liquorix kernel, which is supposedly better for this kinda thing. I dunno if itโs placebo but stuff feels a bit snappier now? My mouse feels more responsive. Again, dunno if itโs placebo. But anyways, I tried compiling again and it still lags my other stuff.
While I ultimately think your solution is to use a different scheduler, and that the most useful responses youโve gotten have been about that; and that I agree with your response that Linux distros should really be tuning the scheduler for the UI by default and let developers and server runners take the burden of tuning differently for their workloadsโฆ all that said, I canโt let this comment on your post go by:
which is good, you want it to compile as fast as possible after all
If fast compile times are your priority, youโre using the wrong programming language. One of Goโs fundamental principles is fast compile times; even with add-on caching tooling in other languages, Go remains one of the fastest-compiling statically compiled, strongly typed programming languages available. I will not install Haskell programs unless theyโre precompiled bin packages, thatโs a hard rule. I will only reluctantly install Rust packages, and will always choose bins if available. But Iโll pick a -git Go package without hesitation, because they build crazy fast.
Anyway, I hope you find the scheduler of your dreams and live happily ever after.
I only said as fast as possible - I generally think the compile times are fine and not a huge problem. Certainly worth it for all the benefits.
Thereโs no free lunch after all. Goโs quick compilation also means the language is very simple, which means all the complexity shifts to the programโs code.
Thatโs an interesting take - that Go program code is more complex than Rust - if I understood you correctly. I came across a learning curve and cognitive load readability comparison analysis a while back, which I didnโt save and now canโt find. I havenโt needed it before because I think this is the first time Iโve heard anyone suggest that Rust code is less complex than Go.
Your point about the tradeoff is right, but for different reasons. Go executables have a substantial runtime (with garbage collection, one of those things that make Go code less complex), making them much larger and measurably slower. And then thereโs Rustโs vaunted safety, which Go - outside of the most basic compile-time type safety - lacks. Lots of places for Rust to claim superiority in the trade-offs, so it tickles me that you choose the one truly debatable argument, โcomplexity.โ
