5 ms·

Well, WSL is Linux. It's really just a VM of it (since WSL2, WSL1 was actually running on the windows kernel which was pretty cool). The big drawback to WSL to

Well, WSL is Linux. It's really just a VM of it (since WSL2, WSL1 was actually running on the windows kernel which was pretty cool). 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

ActorNightly 1y ago
>The big drawback to WSL to me is the slow filesystem access because NTFS sucks Thats if you are going from VM/host. If you use the allocated space for VM, its pretty fast.
xPaw 1y ago
Slow IO is why I still use wsl1.
- ohashi 1y ago
  I liked the networking in WSL1 more too
  - brewmarche 1y ago
    Corporate networking is why I still use WSL1 (I didn’t spend enough time to check why it doesn’t with WSL2, zScaler could be the culprit maybe). 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-1094123281 https://github.com/microsoft/WSL/issues/8219#issuecomment-10... and I don’t think they’re fixing bugs in WSL1 anymore
- psyclobe 1y ago
  This. WSL was SO much more interesting in v1 times.
deetz 1y ago
still use WSL1 also because VMWare runs so dreadfully slow with any kind of Hyper-V enabled - if so, VMWare must also use it, so you get a Type-2 running under a Type-1 the lag is untennable lag and performance.
teruakohatu 1y ago
I use it, I am required to use Windows, and it’s a huge improvement over doing Data Science on native Windows, but the terrible filesystem access ruins what otherwise would be a seamless experience. 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.
JackSlateur 1y ago
Is it really a NTFS issue ? The culprit would be the plan9 bits (think of smb or nfs but .. wilder ? why are they using 9P again ?)
- garblegarble 1y ago
  I'm guessing they use plan9 because distros already ship support for it, and it's super simple compared to NFS? It doesn't seem like CIFS/NFS would be any faster, and they introduce a lot more complexity.
arghwhat 1y ago
NTFS is not the problem. 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.
- cma 1y ago
  >The problem is Windows IO filters 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.
  - arghwhat 1y ago
    WSL2, in my testing, is orders of magnitude faster at file heavy operations than anything outside WSL, dev drive or not. We have an R&D department that's using WSL2 and jumping through hurdles of forwarding hardware because it's night and day compared to trying under windows on the same machine. It provided other benefits too, but the sheer performance was the main selling point. 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,
jmmv 1y ago
> NTFS sucks Watch https://www.youtube.com/watch?v=qbKGw8MQ0i8 https://www.youtube.com/watch?v=qbKGw8MQ0i8 please.
- garblegarble 1y ago
  While I can see the subtle distinction you're trying to draw people's attention to (NTFS is not the problem, filesystem operations generally on Windows are the problem) I have to say it seems like a distinction without a difference in real terms. They made a range of changes that seem to produce more complicated code everywhere because the overhead of various filesystem tasks are substantially higher on this OS vs every other OS. 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
phendrenad2 1y ago
Where are you experiencing filesystem slowness? I've been using WSL in some advanced configurations (building Win32 apps by cross-compiling from Linux CLANG and dropping the .exe into a Windows folder, copying large files from Linux->Windows and vice versa, automating Linux with .BAT files, etc.) and I haven't seen this slowness at all.

ActorNightly 1y ago

>The big drawback to WSL to me is the slow filesystem access because NTFS sucks Thats if you are going from VM/host. If you use the allocated space for VM, its pretty fast.

xPaw 1y ago

Slow IO is why I still use wsl1.

ohashi 1y ago
I liked the networking in WSL1 more too
- brewmarche 1y ago
  Corporate networking is why I still use WSL1 (I didn’t spend enough time to check why it doesn’t with WSL2, zScaler could be the culprit maybe). 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-1094123281 https://github.com/microsoft/WSL/issues/8219#issuecomment-10... and I don’t think they’re fixing bugs in WSL1 anymore
psyclobe 1y ago
This. WSL was SO much more interesting in v1 times.

deetz 1y ago

still use WSL1 also because VMWare runs so dreadfully slow with any kind of Hyper-V enabled - if so, VMWare must also use it, so you get a Type-2 running under a Type-1 the lag is untennable lag and performance.

teruakohatu 1y ago

I use it, I am required to use Windows, and it’s a huge improvement over doing Data Science on native Windows, but the terrible filesystem access ruins what otherwise would be a seamless experience. 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.

JackSlateur 1y ago

Is it really a NTFS issue ? The culprit would be the plan9 bits (think of smb or nfs but .. wilder ? why are they using 9P again ?)

garblegarble 1y ago
I'm guessing they use plan9 because distros already ship support for it, and it's super simple compared to NFS? It doesn't seem like CIFS/NFS would be any faster, and they introduce a lot more complexity.

arghwhat 1y ago

NTFS is not the problem. 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.

cma 1y ago
>The problem is Windows IO filters 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.
- arghwhat 1y ago
  WSL2, in my testing, is orders of magnitude faster at file heavy operations than anything outside WSL, dev drive or not. We have an R&D department that's using WSL2 and jumping through hurdles of forwarding hardware because it's night and day compared to trying under windows on the same machine. It provided other benefits too, but the sheer performance was the main selling point. 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,

jmmv 1y ago

> NTFS sucks Watch https://www.youtube.com/watch?v=qbKGw8MQ0i8 https://www.youtube.com/watch?v=qbKGw8MQ0i8 please.

garblegarble 1y ago
While I can see the subtle distinction you're trying to draw people's attention to (NTFS is not the problem, filesystem operations generally on Windows are the problem) I have to say it seems like a distinction without a difference in real terms. They made a range of changes that seem to produce more complicated code everywhere because the overhead of various filesystem tasks are substantially higher on this OS vs every other OS. 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

phendrenad2 1y ago

Where are you experiencing filesystem slowness? I've been using WSL in some advanced configurations (building Win32 apps by cross-compiling from Linux CLANG and dropping the .exe into a Windows folder, copying large files from Linux->Windows and vice versa, automating Linux with .BAT files, etc.) and I haven't seen this slowness at all.