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.

  • tatterdemalion@programming.dev
    112·
    9 days ago

    Sounds like Kubuntu’s fault to me. If they provide the desktop environment, shouldn’t they be the ones making it play nice with the Linux scheduler? Linux is configurable enough to support real-time scheduling.

    FWIW I run NixOS and I’ve never experienced lag while compiling Rust code.

    • SorteKanin@feddit.dkOP
      8·
      9 days ago

      I have a worrying feeling that if I opened a bug for the KDE desktop about this, they’d just say it’s a problem of the scheduler and that’s the kernel so it’s out of their hands. But maybe I should try?

  • SorteKanin@feddit.dkOP
    81·
    9 days ago

    So I just tried using nice -n +19 and it still lags my browser and my UI. So that’s not even a good workaround.

    • BB_C@programming.dev
      1·
      8 days ago

      Is your browser Firefox?
      What kind of storage devices do you have? NVMe?
      Did you check with tools like iotop to see if something is going on IO wise?

      You assumed that the problem is caused by the CPU being utilized at 100%.
      This may not be the case.

      A lot of us don’t run a DE at all. I myself use Awesome WM.
      For non-tilers, Openbox with some toolbar would be the ideal setup.

      I mention this because we (non-DE users) would have no experience with some funky stuff like a possible KDE indexer running in the background killing IO performance and thrashing buffered/cached memory.

      Also, some of us run firefox with eatmydata because we hate fsync 🤨

      Neither KDE nor Gnome is peak Desktop Linux experience.
      Ubuntu and its flavors is not peak distro experience either.

      If you want to try Desktop Linux for real, you will need to dip your toes a little bit deeper.

      • SorteKanin@feddit.dkOP
        5·
        8 days ago

        Yes Firefox, yes NVMe. No, there is no IO happening and again, sitting at relatively low memory usage. I was not running anything else than the compiler, my editor and Firefox. I’m fairly confident the CPU usage is the culprit as memory usage is not severely affected and disk usage by the compiler should be pretty minimal (and I don’t see how disk usage would make Firefox slow if there’s still plenty of RAM available).

        Neither KDE nor Gnome is peak Desktop Linux experience. Ubuntu and its flavors is not peak distro experience either.

        If you want to try Desktop Linux for real, you will need to dip your toes a little bit deeper.

        I’ve heard much of the opposite - KDE is touted as an easy-to-use desktop and Ubuntu is largely a popular “just works” distro. And honestly that has been my primary experience. Mostly everything works, but there are some hiccups here and there like the problem I posted about in this thread.

        What alternative would you suggest?

        • BB_C@programming.dev
          13·
          8 days ago

          What alternative would you suggest?

          A, rolling release first, distro (e.g. Arch or Void) with no DE installed.
          But you’re probably not ready for that.
          For me, a terminal and Firefox are the only GUI apps really needed. mpv too if it counts.
          But I’m someone who has been running Arch+AwesomeWM for ~15 years ago (been using Arch for even longer). So I probably can’t meaningfully put myself in new users’ shoes.

  • Not a replicant@lemmy.worldаҧсуа бызшәа
    6·
    9 days ago

    Firefox on my raspberry pi grinds the thing to a halt, so I created a shortcut:

    systemd-run --scope -p MemoryLimit=500M -p CPUQuota=50% firefox-esr

    You say it doesn’t top out on memory, so you don’t need the -p MemoryLimit=500M parameter. Set your compiler CPUQuota to maybe 80%, or whatever you can work out with trial and error.

  • eberhardt@discuss.tchncs.de
    2·
    8 days ago

    Actually, I’ve experienced the opposite. I find Windows lagging much more often than Linux when compiling something, especially since Linux switched to the EEVDF scheduler. The most important factor that influences lag on both systems seems to be the power profile though. If I set my power profile to save battery, the system lags from time to time but if I set it to performance it basically never happens (on GNOME you can change that in the quick menu, not sure about KDE). It might be that your Windows is simply tuned more towards performance by default at the cost of higher power consumption.

  • RatsOffToYa@lemmy.world
    5·
    9 days ago

    All the comments here are great. One other suggestion I didn’t see: use chrt to start the build process with the sched_batch policy. It’s lower than sched_other, which most processes will be in, so the compilation processes should be bumped off the CPU for virtually everyone else

  • potajito@lemmy.dbzer0.com
    31·
    8 days ago

    Are you on x11 or wayland? For me x11 behaves really bad on these situations, and wayland is much much snappier.

  • Valmond@lemmy.world
    2·
    8 days ago

    My work windoz machine clogged up quite much recompiling large projects (GB s of C/C++ code), so I set it to use 19/20 “cores”. Worked okayish but was not some snappy experience IMO (64GB RAM & SSD).

  • DefederateLemmyMl@feddit.nl
    1·
    8 days ago

    Hmm, I can’t say that I’ve ever noticed this. I have a 3950x 16-core CPU and I often do video re-encoding with ffmpeg on all cores, and occasionally compile software on all cores too. I don’t notice it in the GUI’s responsiveness at all.

    Are you absolutely sure it’s not I/O related? A compile is usually doing a lot of random IO as well. What kind of drive are you running this on? Is it the same drive as your home directory is on?

    Way back when I still had a much weaker 4-core CPU I had issues with window and mouse lagging when running certain heavy jobs as well, and it turned out that using ionice helped me a lot more than using nice.

    I also remember that fairly recently there was a KDE/plasma stutter bug due to it reading from ~/.cache constantly. Brodie Robertson talked about it: https://www.youtube.com/watch?v=sCoioLCT5_o

  • agilob@programming.devEnglish
    21·
    6 days ago

    EDIT: Tried nice -n +19, still lags my other programs.

    yea, this is wrong way of doing things. You should have better results with CPU-pinning. Increasing priority for YOUR threads that interact all the time with disk io, memory caches and display IO is the wrong end of the stick. You still need to display compilation progress, warnings, access IO.

    There’s no way of knowing why your system is so slow without profiling it first. Taking any advice from here or elsewhere without telling us first what your machine is doing is missing the point. You need to find out what the problem is and report it at the source.

    • SorteKanin@feddit.dkOP
      31·
      8 days ago

      I actually tried that but I had to reduce it all the way to 4 jobs, which slows compilation down a lot.

    • agilob@programming.devEnglish
      11·
      8 days ago

      The CPU is already 100% busy, so changing number of compilation jobs won’t help, CPU can’t go faster than 100%.

  • FizzyOrange@programming.dev
    79·
    8 days ago

    No. And even worse is Linux’s OOM behaviour - 99% of the time it just reboots the machine! Yes I have swap and zswap.

    Linux is just really bad at desktop.

  • prof@infosec.pub
    35·
    9 days ago

    Ha, that’s funny. When I run some Visual Studio builds on Windows it completely freezes at times.

    Never have that issue on EOS with KDE.