The big drawback to WSL to me is the slow filesystem access because NTFS sucks. And having to deal with Windows in the first place.
Ps I wouldn't worry about your karma. It's just a number :P
The problem is Windows IO filters and whatnot, Microsoft Defender trying to lazily intercept every file operation, and if you're crossing between windows and Linux land, possibly 9pfs network shares.
WSL2's own disk is just a VM image and fairly fast - you're just accessing a single file with some special optimizations. Usually far, far more responsive than anything done by windows itself. Don't do your work in your network-shared windows home folder.
Not the biggest issue of them, 'find' and 'git status' on WSL2 in a big project is still >100 times slower on windows dev drive which avoids those filters than it is with WSL 1 on dev drive.
WSL 1 on regular ntfs with defender disabled is about 4x slower than WSL1 on dev drive, so that stuff does cause some of it, but WSL2 feels hopelessly slow. And wsl 2 can't share memory as well or take as much advantage of the filesystem cache (doubling it if you use the windows drive in both places I think, unless the network drive representation of it doesn't get cached on the WSL2 drive.
WSL2 does not take less advantage of filesystem caches. Linux's block cache is perfectly capable. HyperV is a semi-serious hypervisor, so it should be using a direct I/O abstraction for writing to the disk image. Memory is also balloning, and can dynamically grow and shrink depending on memory pressure.
Linux VM's is something Microsoft has poured a lot of money into optimizing as that's what the vast majority of Azure is. Cramming more out of a single machine, and therefore more things into a single machine, directly correlates with profits, so that's a heavy investment.
I wonder why you're seeing different results. I have no experience with WSL1, and looking into a proprietary legacy solution with known issues and limited features would be a purely academic exercise that I'm not sure is worth it.
(I personally don't use Windows, but I work with departments whose parent companies enforce it on their networks,
Files on the WSL2 disk image work great. They're complaining about accessing files that aren't on the disk image, where everything is relayed over a 9P network filesystem and not a block device. That's the part that gets really slow in WSL2, much slower than WSL1's nearly-native access.
> Memory is also balloning, and can dynamically grow and shrink depending on memory pressure.
In my experience this works pretty badly.
> a proprietary legacy solution with known issues and limited features
Well at least at the launch of WSL2 they said WSL1 wasn't legacy, I'm not sure if that has changed.
But either way you're using a highly proprietary system, and both WSL1 and WSL2 have significant known issues and limited features, neither one clearly better than the other.
My understanding is when you access files on the windows drive, the linuxvm in WSL2 caches it in its own memory, and the windows side caches it in its: now you have double the memory usage on disk cache where files are active on both, taking much less advantage of caches than if you had used WSL1 where windows serves as the sole cache for windows drives.
I'm only comparing working on windows filesystems that can be accessed by both. My use case is developing on large windows game projects, where the game needs the files fast when running, and WSL needs the files fast when searching code, using git, etc. WSL1 was usable on plain NTFS, and now much closer to ext4 with dev drive NTFS. WSL2 I couldn't make fast.
You could potentially have the windows files on a network drive on the WSL2 side living in native ext4, but with that you get the double filesystem caching issue, and you might slow a game editor launch on the windows side by way too much, your files are inaccessible during upgrades and you have to always have RAM dedicated to WSL2 running to be able to read your files. MS store versions of WSL2 will even auto upgrade while running and randomly make that drive unavailable.
WSL is for when you actually need it to be Linux.
I do windows and android gamedev and the server side is Linux.
However, WSL1 is pretty much abandoned and lots of newer distros have moved to forcing systemd or container based stuff that doesn't work in it, and some elf binaries no longer work in it (including newer node.js versions).
I use WSL2 as well when I really need it to be Linux and am doing webdev or something.
I use msys2 for a few things, usually compiling windows dependencies with the gnu toolchain that need GCC's stuff like inline assembly or computed goto (codecs etc.). Maybe possible from wsl1 too but they usually have full build and dependency instructions for msys2.
It’s fine for running small models but when you get to large training sets that don’t fit in RAM it becomes miserable.
There is a line where the convenience of training or developing locally gives way to a larger on demand cloud VM, but on WSL the line is much closer.
However it’s not perfect, for example I hit this bug when trying to run node a few days ago https://github.com/microsoft/WSL/issues/8219#issuecomment-10... and I don’t think they’re fixing bugs in WSL1 anymore
Thats if you are going from VM/host. If you use the allocated space for VM, its pretty fast.
The culprit would be the plan9 bits (think of smb or nfs but .. wilder ? why are they using 9P again ?)
Watch https://www.youtube.com/watch?v=qbKGw8MQ0i8 please.
But in the end they had to get the OS vendor to bless their process name anyway, just so the OS would stop doing things that tank the performance for everybody else doing something similar but who haven't opened a direct line up with the OS vendor and got their process name on a list.
This seems like a pain point for the vendor to fix, rather than everybody shipping software to their OS