Windows 11 vs. Ubuntu Linux Performance Is Very Close On The AMD Ryzen 9 7950X

[jacob]

Windows will never reach Linux performance. It would have to be rewritten completely. There's something strange going on in above tests. I bet the final Linux 6.1 would wipe the floor with Windows as usual.

Windows is not inherently slow, NTFS is. Linux will blow it out of the water in any benchmark that uses IO or filesystem operations, where NTFS would hold it back against Ext4, XFS or Btrfs. Which is ironic because for a while, NT (the predecessor of modern Windows) had better IO performance than then-Linux.

[rabcor]

Win 11 got lucky, if michael had tested large file copy ...

Ubuntu (or just linux...) got lucky, if microsoft had tested copying files from one hard drive to another... (try it, it's fucking atrociously slow, tried copying an 80gb game between ssds, it went so slow i might have actually been able to re-download it entirely faster; Just let me repeat that: SSDs)

Speed so bad I'm thinking even a unicore pc with windows 95 and PATA HDDs could have possibly done it faster.

[Anux]

tried copying an 80gb game between ssds, it went so slow

That's strange, maybe you copied it to ntfs or something. I'm always capped by hardware on copying stuff. Sure small files are slower but that ain't faster with Win either.

[mdedetrich]

Sure I'm already seeing all those Win users firing up their cmd and fiddling with robocopy.

There is also a GUI for it but this is a largely pointless exersize because what you are arguing about has nothing to do with Windows being slow but rather the default set of applications.

The equivalent would be claiming that Linux is slow because some distribution ships some slow version of some program.

[Anux]

because what you are arguing about has nothing to do with Windows being slow

I didn't say Windows is slow, I just made a comment about the file copy bug. Windows is slow in many other areas that won't ever get caught by a benchmark.

[mdedetrich]

Windows is not inherently slow, NTFS is. Linux will blow it out of the water in any benchmark that uses IO or filesystem operations, where NTFS would hold it back against Ext4, XFS or Btrfs. Which is ironic because for a while, NT (the predecessor of modern Windows) had better IO performance than then-Linux.

There are also reasons for this. NTFS for example allows you to register hooks (called filters in Windows) that execute whenever certain IO operations happen and applications like Antivirus typically use these hooks.

The existence of having such a design does slow down the filesystem (i.e. batching is really hard), there are other reasons as well.

Windows is slow in many other areas that won't ever get caught by a benchmark.

Thats a non statement that can be used to argue anything.

[jacob]

There are also reasons for this. NTFS for example allows you to register hooks (called filters in Windows) that execute whenever certain IO operations happen and applications like Antivirus typically use these hooks.

The existence of having such a design does slow down the filesystem (i.e. batching is really hard), there are other reasons as well.

But Linux has those as well (LSM), and I presume that no antivirus that uses them is installed when running the benchmarks.

[mdedetrich]

But Linux has those as well (LSM), and I presume that no antivirus that uses them is installed when running the benchmarks.

I think the problem is more to the design space, LSM path hooks (if thats what you are talking about) is an optional part of the kernel (or more accurately Linux system) where as with NTFS its baked into the filesystem itself and it cannot be removed which means that even if you don't have antivirus installed (which isnt the case anymore due to Windows defender, you would need to manually disable it) you still have to pay for the performance cost of the feature.

[jacob]

I think the problem is more to the design space, LSM path hooks (if thats what you are talking about) is an optional part of the kernel (or more accurately Linux system) where as with NTFS its baked into the filesystem itself and it cannot be removed which means that even if you don't have antivirus installed (which isnt the case anymore due to Windows defender, you would need to manually disable it) you still have to pay for the performance cost of the feature.

I'm not sure I follow. A filesystem is a data structure, it can't have callback hooks baked into itself, it's the implementation driver that has them. LSM may be "optional" but it's actually active by default in most distros (used among others by apparmor in Ubuntu, SUSE and derivatives and by SELinux in RedHat, Fedora and derivatives). Either way, when not in use, which is the default case on Windows, the overhead cost of checking that a callback pointer is not set is negligible and the performance impact should be naught. I think there is something very wrong with NTFS itself and the callback API has nothing to do with it.

By the way, if IO benchmarks are ran on out-of-the-box OS installations, then Linux results will include LSM and whatever is built on top of it, whereas on Windows it won't. But NTFS still ends up being dramatically slower. I don't know if it's the design that is fundamentally flawed, or if MS never bothered optimising the driver for it.

[mdedetrich]

I'm not sure I follow. A filesystem is a data structure, it can't have callback hooks baked into itself, it's the implementation driver that has them.

So I managed to find the post I was referring to, read https://github.com/Microsoft/WSL/iss...ment-425272829.

By the way, if IO benchmarks are ran on out-of-the-box OS installations, then Linux results will include LSM and whatever is built on top of it, whereas on Windows it won't. But NTFS still ends up being dramatically slower. I don't know if it's the design that is fundamentally flawed, or if MS never bothered optimising the driver for it.

From what I recall given the design constraints they optimized NTFS as much as they could without breaking backwards compatibility. The link I referenced above claims that.