I appreciate the fact that they waited two months to check their results before sharing them publicly. However, this feels like there should be a hypothesis for explaining the difference other than “this fits expectations”, especially after the author extensively claims this does not fit their own expectations. Did I miss something?
Could this be due to how Windows vs Linux does process scheduling on CPUs with P- and E-cores?
To my knowledge Linux isn’t that capable on BIG.little architectures, and Linux power-management (as this intersects with) has always left a little to be desired - when comparing battery life to Windows.
Disclaimer: pure speculation. Possibly misinformed :-D
If there is a measurable performance differential, then such a big gap is actually a good sign. There is probably one thing massively broken, and not a systems design problem that needs a man-year to resolve if FOSS folks ever agree how to fix it.
If Linux previously always outperformed Windows the result should be similar this time around as well. It could possibly be some missing feature or a bug in the linux drivers but it sounds unlikely to me. I mean the architecture isn't fundamentally different. Maybe windows ignores some thermal throttling? Something smells fishy here for sure.
I recently learned that my device won't display UHD movies in Linux on my projector because HDMI is vendor-locked to Windows... Maybe this is something similar (a driver that was not done right)
I'm surprised the choice of operating system can have such a large impact on performance. I would have expected the performance was more dependent on the application, not the OS.
There is no context here for most obvious and important differences between Windows and Linux. Nor does this article note the furor over the forced obsolesce of millions of PC's because of (drum roll) Windows 11.
Responsible articles and journals note these things.
This looks less like “windows is outperforming” and more like “Linux in this config is severely handicapped by <issue> and is running at 50% of potential”
As a scientist myself I would do my best to figure out why before publishing something like this.
As much as I want to use Linux on the desktop I've had terrible cases of instability:
My hardware on Windows 10 works perfectly well. Literally 11 years of being super stable, running assorted workloads (WSL 2, Docker based development, browsers, heavy terminal based workflows with Neovim, tmux, etc., video recording and editing, image editing, gaming, etc.). There's no lag, jittering or instability. My system never crashes or has weird issues requiring a reboot on Windows 10.
1 day into using Arch Linux, as soon as my GPU's memory gets close to 75% full then apps crash, my Wayland based window compositor (niri) starts to fail in unpredictable ways and I have to reboot basically every 3 hours because of GPU memory usage.
It's not stable or very usable IMO.
All I did was open 3 Firefox windows and 2 Ghostty terminals. Both apps are hardware accelerated so they use GPU memory.
Windows seems like it does something magical with how it offloads GPU requested memory to system memory in a transparent way if GPU memory is full but Linux, at least with the official proprietary 580 series DKMS NVIDIA drivers doesn't seem to do this with my GTX 750 Ti. Instead, I get kernel errors from the NVIDIA drivers when it fails to allocate memory, such as:
kernel: [drm:nv_drm_gem_alloc_nvkms_memory_ioctl [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000100] Failed to allocate NVKMS memory for GEM object
It's wild that my system can be using 2 GB out of 16 GB of system memory at 5% CPU load with no disk I/O happening but I can't run a few apps in parallel, it's especially bad when trying to record 1080p videos with OBS. I recorded literally over 1,000 videos on Windows without a single hiccup.
I have to hand it to Windows with how it manages system memory and "just works", especially with older hardware.
Also as an aside, Ghostty on this Linux machine is very slow compared to the Windows Terminal. Opening half a dozen Neovim splits on my 4k monitor completely tanks its performance to where there's a lot of input lag and jitters. The screen redraws are very slow. The Microsoft Terminal had no issues with the same Neovim version and configs running in Arch Linux within WSL 2, it was buttery smooth. I opened a discussion about this on Ghostty with more information https://github.com/ghostty-org/ghostty/discussions/10114.
In 2019 I tried switching to native Linux and it failed with my Scarlett 2i2 USB audio interface. I got endless crackles and pops and after 5 days of debugging and trying everything I gave up and went back to Windows.
In Dec 2025 I tried switching to native Linux with the same hardware and the audio problems are solved but now there's this GPU memory problem. I spent another few days debugging as much as I could but it's looking like it's back to Windows.
I think the GPU issues probably won't be solved in 7 years because NVIDIA said they are going to end of life the 580 series drivers in August 2026 and the 590+ series don't support my card. The open source drivers produced a worse experience, it wouldn't let me use my 4k monitor and hard locked my machine a few times.
Have some oe on something similar, we created two laptops that ran Linux to mimic something in our plant, the issue with them though was drivers, we got the bleeding edge and components like the network card and graphics card just didn't work for a month or two until new drivers came out. It was red hat from maybe 2020 time frame.
It could be that they chose something bleeding edge and the hardware drivers were built for windows but might be a couple revisions behind for the Linux equivalents. It could be the development cycle for windows vs that of Linux and how they integrate with new hardware. Just a hypothesis.
This is a strange test to care about. As if people choose linux vs. windows based off of performance on one specific benchmark on one specific hardware platform.
21 comments
[ 3.3 ms ] story [ 44.6 ms ] threadTo my knowledge Linux isn’t that capable on BIG.little architectures, and Linux power-management (as this intersects with) has always left a little to be desired - when comparing battery life to Windows.
Disclaimer: pure speculation. Possibly misinformed :-D
https://news.ycombinator.com/item?id=46002989
(i.e. no license, have to fallback to unaccelerated software-only implementation)
The consumer loses out but that's not something new either.
Responsible articles and journals note these things.
As a scientist myself I would do my best to figure out why before publishing something like this.
As much as I want to use Linux on the desktop I've had terrible cases of instability:
My hardware on Windows 10 works perfectly well. Literally 11 years of being super stable, running assorted workloads (WSL 2, Docker based development, browsers, heavy terminal based workflows with Neovim, tmux, etc., video recording and editing, image editing, gaming, etc.). There's no lag, jittering or instability. My system never crashes or has weird issues requiring a reboot on Windows 10.
1 day into using Arch Linux, as soon as my GPU's memory gets close to 75% full then apps crash, my Wayland based window compositor (niri) starts to fail in unpredictable ways and I have to reboot basically every 3 hours because of GPU memory usage.
It's not stable or very usable IMO.
All I did was open 3 Firefox windows and 2 Ghostty terminals. Both apps are hardware accelerated so they use GPU memory.
Windows seems like it does something magical with how it offloads GPU requested memory to system memory in a transparent way if GPU memory is full but Linux, at least with the official proprietary 580 series DKMS NVIDIA drivers doesn't seem to do this with my GTX 750 Ti. Instead, I get kernel errors from the NVIDIA drivers when it fails to allocate memory, such as:
It's wild that my system can be using 2 GB out of 16 GB of system memory at 5% CPU load with no disk I/O happening but I can't run a few apps in parallel, it's especially bad when trying to record 1080p videos with OBS. I recorded literally over 1,000 videos on Windows without a single hiccup.I wrote a lot more details about this Linux issue in an Ask HN but it didn't gain traction https://news.ycombinator.com/item?id=46436245.
I have to hand it to Windows with how it manages system memory and "just works", especially with older hardware.
Also as an aside, Ghostty on this Linux machine is very slow compared to the Windows Terminal. Opening half a dozen Neovim splits on my 4k monitor completely tanks its performance to where there's a lot of input lag and jitters. The screen redraws are very slow. The Microsoft Terminal had no issues with the same Neovim version and configs running in Arch Linux within WSL 2, it was buttery smooth. I opened a discussion about this on Ghostty with more information https://github.com/ghostty-org/ghostty/discussions/10114.
In 2019 I tried switching to native Linux and it failed with my Scarlett 2i2 USB audio interface. I got endless crackles and pops and after 5 days of debugging and trying everything I gave up and went back to Windows.
In Dec 2025 I tried switching to native Linux with the same hardware and the audio problems are solved but now there's this GPU memory problem. I spent another few days debugging as much as I could but it's looking like it's back to Windows.
I think the GPU issues probably won't be solved in 7 years because NVIDIA said they are going to end of life the 580 series drivers in August 2026 and the 590+ series don't support my card. The open source drivers produced a worse experience, it wouldn't let me use my 4k monitor and hard locked my machine a few times.
It could be that they chose something bleeding edge and the hardware drivers were built for windows but might be a couple revisions behind for the Linux equivalents. It could be the development cycle for windows vs that of Linux and how they integrate with new hardware. Just a hypothesis.