> The clue is that MSWin running in a VM on Linux is faster than on hardware.

I'll join the fray in expressing skepticism here. Source?

Anyway, I think this WSL distro is pretty cool. I've set up WSL on my Windows computer for kicks and while it was neat I never quite got it to work for the rust development and environment I wanted. I ended up just doing it in Windows.

But if this sets up rust and VS Code (the editor I wanted to use) painlessly, then I'll have to give it another shot.

The filesystem is notably slower on Windows. It's easy to test it out for yourself; clone any big repo (eg: linux) in WSL and run `git status`. The Microsoft engineers have already done a lot of heroic efforts with WSL. The issue seems to be more inherent to the design and really hard to solve.

ref: https://github.com/Microsoft/WSL/issues/873

To be clear, this is for a specific use-case. I don't believe that all applications will have similar performance profiles and that Linux wins over Windows in all of the cases like OP seems to suggest.

It's definitely true in my experience that disk operations are slower in Windows. Folks on this thread are getting flack for poor comparisons (IMO Windows is worse at lots of small files), but even when you remove that, and say, look at mostly portable code that deals with a single file, as I have seen using sqlite as an example, it does worse.

Not to mention Windows has built in antivirus reacting to all your filesystem activity by default...

It's entirely possible to disable this by adding an exception for the WSL directory in Windows Defender. In my experience, this vastly improves IO from within linux.

Good luck convincing your employer to do this. One feature request from me in case someone from MSFT is reading - please design things so that no file modify hooks are invoked at all for files under wsl directory. Files in wsl should be in a secure sandbox by default outside the reach of any antivirus.

I have heard that system devs at Microsoft have Admin mode enabled. I think that is why they dont realise how bad the dev experience is on windows when you dont have admin. You cant turn windows indexing off, you cant exclude things from anti virus, you cant launch Application Verifier. All dev workflows should work without Admin.

I am reliably informed that the top developers ay MS Research are in WSL 80% of the time.

Satya,if you are reading this - Do an experiment by taking away everyones admin privileges for two weeks. See how many people can still do their jobs. Fix every single developer use case you find that needs admin.

I wasn't talking about WSL at all actually. I have never used it. Disk performance is just worse on Windows. With or without defender. (And defender is the default.)

Based on limited testing, I think IO is slower on Windows even when there's no filesystem involved at all. The block layer is just slower, despite having so few features that it's hardly worthy of being called a layer compared to what's possible on Linux.

Based on my limited testing, a VM running on a NTFS file backed disk runs just as fast natively.

The WSL filesystem. That says nothing about the question.

Windows supports multiple file systems; Microsoft could solve this by adding ext4 support directly into Windows and running WSL from a separate partition.

No, because you still suffer from Windows buffer management, Windows I/O scheduling, and Windows kernel-thread scheduling.

It has been tried.

I don’t believe your assertion. A quick check on the latest system-taxing application (aka a game), confirms the exact opposite. Even a cross-platform game, compiled natively for both OSes, runs faster on Windows in most cases. How do you square these observations with your assertion.

I assume you are limiting your definition of "system-taxing" to playing games specifically?

As other people have noted, filesystem performance is often better under Linux.

I also will point out that at least some rendering tasks can be faster under Linux as well:

http://blog.thepixelary.com/post/167616662857/improving-perf...

Just like with the filesystem performance discrepancy, this article seems to point out WDDM (Windows drivers) as the reason for this rendering discrepancy.

And while we are on gaming (since I am a gamer as well!) when comparing games that run natively on Linux as well as Windows, Linux often has a performance edge over Windows:

https://www.phoronix.com/scan.php?page=news_item&px=Win10-Li...

Of course most games do not support Linux natively so in order to game on Linux you have to use WINE, Proton, or full virtualization to get a non-native game to run and this extra middleware layer adds overhead. But this doesn't mean gaming performance on Linux is worse than Windows; as comparing native-to-native performance shows.

Using git as a filesystem performance metric is horribly flawed -- git was written from the beginning to perform perfectly on Linux. It's the most native linux application I can think of.

(Not because it's using secret system calls, but because its design was vetted and performance tailored for Linux.)

I didn't really specify git myself, but it doesn't seem like NTFS is a particularly high performance filesystem these days:

https://www.phoronix.com/scan.php?page=news_item&px=Linux-4....

https://www.makeuseof.com/tag/linux-transfer-files-faster-wi...

https://www.tomshardware.com/reviews/ubuntu-oneiric-ocelot-b...

https://superuser.com/questions/1124472/why-is-linux-30x-fas...

I also want to point out that just because NTFS isn't the fastest filesystem on the block doesn't mean it is a bad one. From what I can gather just casually googling it seems like NTFS emphasizes safety at the cost of performance at times. So depending on your workload and desired behavior NTFS might be the file system of choice for you. It's also worth noting that IF NTFS is intended to be more user-safe it sort of makes sense why may be the choice for the most common OS which aims to serve all users (not just technical ones).

I thought it was mainly because windows doesn't have a dir cache in the kernel. The WSL filesystem performance thread is linked above which goes into this.

And that can't be fixed without involving 10 different teams and potentially outside partners.

And there's something wrong with the filesystem, which can't be fixed without the same deal except that will definitely require the cooperation of the outside partners because apparently you can write an extension for NTFS and fixing it would break the existing extensions, which Microsoft doesn't have the source for and doesn't ship.

And there's a thousand other paper cuts, and a very large fraction of those would require cross-team coordination and testing, which is a horrible time sink in a large company.

Fundamentally, Windows has poor performance when dealing with lots of little files, which is exactly what compiling large code bases involves. And to top it all off, their build system, conspires against their own OS. You'll get better performance using cmake + ninja (on Windows that is) then you will with cmake + visual studio.

Edit: also as a practical matter, if all my company's code is in git, and all outside code bases I work with are in git, I kinda would like decent git performance regardless of the origins of the tool.

I use windows as an outlook appliance at work, and as a gaming appliance at home. Otherwise I do everything in linux and am much happier.

It is also extremely slow on big files. Try opening a file, seeking out to 10GB, and writing 4KB. Instant, on any Unix. Better have something else planned for the afternoon, on Windows.

Games really aren't a good benchmark for overall system performance as they are generally optimized for Windows and non-Windows ports often receive a lot less attention. Also, most games are primarily stressing one thing - the graphics stack - and not I/O, scheduling, memory management etc.

Which game? I don't agree with the position of the person to whom you are responding, but there's almost certainly much more optimization put into the Windows version.

Why is “much more optimization” a limitation? What is preventing devs from optimizing the linux version? If the OS is more performant that should require less effort, no?

My point is more that a game's performance is not necessarily a reliable way to measure relative performance of the OS. What game was it?

Windows absolutely dwarfs Linux when it comes to gaming market share. Game developers will factor in return on investment and therefore a proportional amount time will be spent on optimizing the Linux port.

> MSWin running in a VM on Linux is faster than on hardware.

That's funny. I didn't know that. Any data source you can share with me?

It seems a highly counterintuitive thing to say but I have anacdotelly noticed the same when running XP bare metal vs inside a VM running in Linux on the same hardware. Around that era I have hard others notice the same on their PCs as well - and that’s where the origins of this meme comes from. I didn’t spend any time investigating why Windows might perform differently since running the BM was just to save dual booting rather than any performance related reasons however I think it was primarily around file system operations where the difference was noticeable (this was before SSDs were ubiquitous).

Microsoft have invested considerable effort on improving the NT subsystem in subsequent releases of Windows so I would be surprised if that meme was still true. Plus SSDs likely even the playing field too.

Apps certainly have been for a long time.

IE6 was famously (in my parts) known for being perceivably faster under Wine.

Wine is not a VM though.

I thought wine is not an emulator:)

> That way MSWin relies on the underlying OS to do things MSWin has proven to be just not very good at

Could you expand on what some of these things are?

File operations. Corralling vendors to code reliable, non-crashy drivers. Input device event handling. Thread scheduling. I/O scheduling. Anything where tuning would have involved work by more than one product group.

Even if your claim that running windows in a VM on hardware that have no Linux support, only windows support, is somehow feasible and faster... That kinda misses the point? Freebsd and windows have Linux binary support. I don't see why having a project catering to one of those would be "the wrong approach"? There's been some pretty successful efforts in helping games run under wine, as a "reverse" example.

I think you'd want to qualify just which parts of which particular Windows applications running in a VM on Linux are faster. I see you refer to the filesystem driver, and that makes sense to me. However, if it's anything related to pro audio or 3D applications native to Windows, it would not square with my experience. Stability is also an important word to bring up here -- I haven't had a bad experience with WINE on Linux if it works. If it doesn't, I get odd behavior and crashing.

I can run three displays natively on my Win 10 machine pretty effectively on a small Dell laptop. Linux is pretty poor at multi-screen support from my experience although it might have improved.

As I have a corporate laptop running Win10 I can't install anything except use Cygwin or WSL. It doesn't allow me to run a Linux VM as it has networking issues upon installing Hyper-V or Virtualbox.

So I'm stuck with WSL on Win 10 and appreciate the efforts of others to get X apps running on it.

It works well enough for me. I have no great love for Windows, but then the only available alternatives have proven worse for me (both osx & linux each used f/t for several years).

There are no good desktop os's in 2019, so they're all 'wrong'. Being 'wrong' therefore cannot be a good argument against their use. All we can do is find the best compromise for our purposes.

The conceptual foundation to do something like this already exists in the form of Drawbridge and Hyper-V, there just needs to be a political will within Microsoft to make it happen.

I don't know if it's the wrong direction or not. I suppose it depends on what your goals are.

All I can say is that I don't see the need for any of it.

I always have difficulties with drivers on linux. Never on Windows. Until they fix that I cannot use anything other than windows as my base system. I don't care if linux handles things slightly better

Difficulties with drivers in terms of quality, availability or both? Regarding availability (and often quality) the only real/sustainable solution is for hardware manufacturers (who I think you are referring to by "they") to improve their Linux support.

There's nothing to fix. The devices are either open and a dev has decided to write his own, or the devices are closed and the drivers are provided by their respective creators.

If it's the former, pay a dev, if it's the latter, use a different device.

There's nothing to fix. The fire is either of a type that may be extinguished and a trained firefighter decided to put this type of fire out for everyone, or the fire is unable to be extinguished as was the intention of the entity that started it.

If it's the former, find the correct firefighter, if it's the latter, use a different fire.

There's nothing to fix. The construction material is either of a type that does not spontaneously combust, and a carpenter can make you a fine chair out of it, or the material is the type to spontaneously combust, and if you choose to buy a chair made of that material you will soon find your pants are on fire.

If it's the former, pay a contractor to build you a chair, or make one yourself. If it's the latter, use a different construction material.

There is nothing to cure. The pathogen is either of a type that is curable, and a licensed medical professional can prepare a treatment regimen, or the pathogen will liquefy all of your internal organs within minutes, and if you choose to expose yourself to the latter pathogen, you will find yourself having a bad day very quickly.

If it's the former, pay a licensed medical professional or read online forums and do it yourself. If it's the latter, contact your nearest funeral home.

Or! Hear me out here: I use Windows.

Lock-in sucks, but it's real.

Yes, but you can run it in a VM. Microsoft could make it run in a container, instead, if they cared about your time. They might do it to make their Azure servers faster, but have little incentive to tell you.