Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #41
    Originally posted by mdedetrich View Post
    So I managed to find the post I was referring to, read https://github.com/Microsoft/WSL/iss...ment-425272829.
    That's an interesting read, thanks for sharing. Still, it only seems to go half way towards explaining the issues. Without being familiar at all with the internals of the NT kernel, it makes me ask the following questions:
    1. Ok so Windows doesn't have a toplevel dentry cache - it begs the question why, and why can't one be implemented? Besides, I'm not sure how much that affects benchmarks where stat() doesn't happen nearly as often; creating tens of thousands of new files and then overwriting them etc. wouldn't be terribly affected by it anyway unless in NT they have to re-resolve the full path every single time, which I doubt they do because it would be a really dumb way to do it? The fact that NT doesn't parse paths at the VFS level like Linux does shouldn't make a difference either (they need to be parsed somewhere), but the optimisation of that particular routine probably does. I remember reading that in the recent Linux kernels, path resolution is done basically without any lock contention, which certainly is a huge performance win - but if so, and if NT doesn't have that, can't MS optimise it?
    2. The description of the "filters" etc seems to suggest (but I could be wrong) that the handlers run in user space. If so then it's something different that Linux doesn't really have a direct equivalent of, the closest thing in Linux-land would likely be some kind of FUSE handler mounted on top of the actual filesystem as an overlay. That would have a huge performance impact indeed. Linux *does* use something vaguely like that too (ecryptfs for example), but it's all in kernel space. But again, it begs one question: why do they have to do this on the system partition (C: ) of all places?
    3. The handle-oriented API sounds like a weird argument. A handle is just what Linux calls a fd and it's used everywhere too. True, in some cases syscalls like unlink() can take a path and not a fd, but at the VFS level the unlink() operation expect an inode and a dentry, which is exactly what a fd ultimately points to. The only difference seems to be that in Windows, they have to resolve the path (which is slow according to the description), return the handle and then invoke another syscall to delete the file, which means they have twice as many context switches. Fair enough, but Linux had been adding syscalls precisely to avoid this type of multiple context switching throughout the years, why can't Windows add a DeleteFileByPath() ?

    Comment


    • #42
      Originally posted by Danny3 View Post
      So it's either that Ubuntu is that bad or Windows that good!
      I think it's the first one.
      Yeah, I still believe in a conspiracy theory in where Ubuntu was made slower in purpose as part of the Microsoft-Canonical pact.

      Comment


      • #43
        Though I don’t see Python oriented tests, why would you use Python 3.7.x on Windows while using Python 3.10.x on Linux?

        Windows isn’t pre bundled with Python so I think you should install the latest.
        Moreover it would be great if you used Clang on Windows.

        Comment

        Working...
        X