Live data from Hacker News

Initial Impressions of WSL 2

daverupert.com

101–110 of 233 posts

Re: Initial Impressions of WSL 2

#101
post #86

Earlier quoted context omitted.

> I thought it was a thin translation layer between the kernels? WSL1 was like that, but it was severely handicapped by NT filesystem performance, especially for small files or metadata operations. There are a lot of small operations that are more than 2 orders of magnitude slower on Windows than on Linux, and a lot of Linux software just expects them to be fast, so WSL1 is not a great experience for a lot of stuff.

Personally I never had a problem with filesystem performance on WSL 1. I certainly don't think it was so bad that the whole thing needed to be scrapped in favor of a virtual machine.

Windows does something weird with the filesystem that I have never figured out. In a msys2 shell, git is incredibly incredibly slow. I actually don't even bother running git in msys2 anymore; I just use the native git in that directory. (I use msys2 to cross-compile AVR stuff.)

This seems to be a known issue, but nobody knows how to fix it. (It's some UAC thing, apparently.) I imagine this is what WSL 1 used, and it was similarly slow.

Re: Initial Impressions of WSL 2

#103
post #97

Earlier quoted context omitted.

Yeah don't get too excited, it's just a VM. The disk usage doesn't automatically shrink with usage, and I'm not sure if RAM does either (interested in knowing if they've done anything related to that), which were what I found most useful about WSL1. I wish they'd instead put all their effort from this into legitimately fixing the issues in WSL1 instead.

> it's just a VM. The disk usage doesn't automatically shrink with usage That's possible in theory, I've done it with libvirt/KVM. You have to enable discard on all filesystems and swap on the guest, use a virtual disk interface which can pass the discard requests to the host, and configure the host to release the corresponding blocks on a discard request. I don't know if WSL2 comes configured to do all that, but if…

I imagine that could cause some awful fragmentation?

Re: Initial Impressions of WSL 2

#104
post #86

Earlier quoted context omitted.

> I thought it was a thin translation layer between the kernels? WSL1 was like that, but it was severely handicapped by NT filesystem performance, especially for small files or metadata operations. There are a lot of small operations that are more than 2 orders of magnitude slower on Windows than on Linux, and a lot of Linux software just expects them to be fast, so WSL1 is not a great experience for a lot of stuff.

Personally I never had a problem with filesystem performance on WSL 1. I certainly don't think it was so bad that the whole thing needed to be scrapped in favor of a virtual machine.

Really? I found it slow enough to basically not be able to use any of my regular build systems (Maven, NPM, Cargo, etc.).

Re: Initial Impressions of WSL 2

#105
post #29
post #3

No free lunch, of course. Faster file access with WSL2 (vs WSL1), if you stay in the Linux world. But if you point it at Windows files (/mnt/c, etc), it's pretty slow. WSL2 just moved the slowness from one side to the other. Accessing the Linux FS from Windows (\\wsl$\) is also slow. That said, I am a fan, and get a lot of use out of WSL1. Since I don't use the Windows interop much, WSL2 should be a performance win f…

Yep. With WSL I can seamlessly access files from both Linux and Windows. I use the Terminal (Windows) and various Unix tools for a lot of stuff (compiling & testing on Posix, objdump, debugging). And I use Windows GUI tools for editing (Sublime), diffing (BeyondCompare), and so on. I get the best of both worlds. But WSL2 file access in `/mnt/c/` is now unbearably slow. So I just stick with WSL1. From what I've read,…

Check out VS Code. It can now read and edit files inside of WSL remotely [1]. I've been using it on a new project and it works almost seamlessly * . I don't know if other editors will get this functionality, but there's really no need now for me to save files in /mnt/c.

[1] https://code.visualstudio.com/docs/remote/wsl

* One curious effect is you can't move folders from VS Code due to permissions. So I have to close it and use Windows Terminal for that, but moving folders doesn't happen too often.

Re: Initial Impressions of WSL 2

#106
post #35

Earlier quoted context omitted.

"Microsoft intends to support both WSL1 and WSL2" I'm not sure I believe them. Maintaining a whole tricky "fake" kernel/translation shim must be a lot of work.

> I'm not sure I believe them. I'm not sure why anyone should. They literally say "We currently have no plans to deprecate WSL 1" while simultaneously claiming "We are committed to making WSL 2 feel the same as WSL 1" . There's no way their goal is to reach a steady state where they feel the same and yet both have to be maintained. Making them feel the same is literally what you do when your goal is to stop support f…

I watched Aaron Patterson's keynote from RailsConf 2020 (these talks all just came out this week, Couch Edition) and I'm struck when reading your comment that it's absolutely possible to do this, and ultimately you may or may not reach a state where it's possible to "end-of-life" one or the other alternative without making anyone cry about it.

He spends most of the second half of the talk explaining (with a profiler) how two query implementations on ActiveRecord which should be doing pretty much about the same thing, actually perform wildly differently, and narrowing it down with data to understand why.

The talk is really interesting and I think it's a parallel to the current discussion in a way because, in Aaron's talk there were two implementations and one was obviously better performing (but unfortunately it was the one that is harder to write.) He argued mostly that, unless there is a reason for these two implementations to behave and perform differently, the one that is slower (but easier to write) should become more like the one that is "enhanced with a performance pro-tip" that arguably the ActiveRecord user shouldn't really need to know about. In other words, that the bad performance was actually a bug.

(tl;dr: the pro-tip is, to build your own pre-sanitized SQL WHERE clause strings, because you may save something like 38% performance in a pathological case, recovered time that the SQL engine was going to spend traversing AST and compiling.)

My point is that, exactly. If there is bad performance over here, it is a bug. Bad performance over there, bug. But bad performance over here, that can only be solved by swapping for bad performance over there?

This does not sound like a bug anymore, it starts to sound more decidedly like a trade-off. But given enough time, perhaps they will fix the bugs, and the two can be made to perform similarly, fixing bugs on either side, and the need for two alternatives will go away. So why would that be bad?

(And if it can't be done, or can't be done yet, why wouldn't we expect to see both implementations maintained as long as needed to find a solution that pareto-dominates them both?)

Re: Initial Impressions of WSL 2

#107
post #80

Big fan of WSL, get power of Windows and the full power of Linux combined. Can easily switch between gaming and development.

One caveat is that WSL2 needs Hyper-V, and many anti-cheats won't work with it (many CS:GO anticheats, I think it will be true for many multiplayer shooters).

There have been games whose anti-cheat software incorrectly flagged Hyper-V hosts as being Hyper-V guests and would refuse to launch the game, but I believe they are all fixed.

All my Blizzard games seem perfectly happy to run on a machine that has Hyper-V.

Re: Initial Impressions of WSL 2

#108
post #62

Earlier quoted context omitted.

You could already do that with WSL1. Source: I have Arch and Ubuntu on WSL1. Those didn't change. Other things did.

They didn't say that something changed. But I'm intrigued, what did change?

I/O performance characteristics changed, your ability to share the same filesystem for both OSes changed, etc.

Re: Initial Impressions of WSL 2

#109
post #83
post #77

Earlier quoted context omitted.

WSL 1 and WSL 2 can coexist and be used according to what needs one's scenarios present. I imagine MS collected enough requirements to also justify a full Linux VM. There will be some slowness somewhere, the 2 versions now let you choose on which side of the boundary to place it. https://docs.microsoft.com/en-us/windows/wsl/wsl2-faq

WSL 2 can't coexist with other virtual machine software though (unless it leverages Hyper-V)

Good chance that your other VM software can't co-exist anyway. Many other technologies, Windows Defender among others, leverage virtualization through Hyper-V.

Re: Initial Impressions of WSL 2

#110
post #95

Big fan of WSL, get power of Windows and the full power of Linux combined. Can easily switch between gaming and development.

I've been using Steam on (Debian) Linux for quite a while and haven't really run into issues. I mostly play Dota 2 and Stellaris, which come Linux native, but also a bunch of other stuff including quite a few Windows native / Proton-"translated" games. All this on AMD graphics with standard open source drivers btw, did not install either proprietary drivers or "special" open source versions. (Card is this in case any…

For several years, I too have used just Linux + Steam for gaming. But lately I have some misgivings.

Recently I've noticed that some games running under Proton don't reliably save: "X-Com 2" and "Strike Suit Zero". And I can't rule out that happening with other games running under Proton.

The frustration of lost saves makes gaming less enjoyable for me. So now I'm considering running Windows 10 in a guest VM.

(I'm not interested in Win10 + WSL, because I'm not open to Win10's unavoidable-updates and forced-telemetry.)

Post reply on HN