Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Windows Subsystem for Linux: The lost potential

jmmv.dev

Post reply on HN
Print view View original

201–210 of 250 posts

Re: Windows Subsystem for Linux: The lost potential

#201

Post by acqq »

neurostimulant wrote: post #170
ASalazarMX wrote: post #73

Earlier quoted context omitted.

Is that an upper bound? My Ubuntu 20.04 console sessions on WSL2 consume a couple tens of Mb.

The individual process inside the vm might not consume much, but the vm itself might reserve some GBs of memory. Try looking at how much memory `vmmem` process used in task manager.

Also:

https://www.reddit.com/r/bashonubuntuonwindows/comments/d8x7...

"So, I was copying a 8GB file to my Debian home folder using Windows Explorer, via $wsl network. The copy process made my CPU's fan runs like a jetplane, and it stop copying when at 95%, then I opened up Task Manager and saw this.

even after it finish copying, Vmmem process still hold 13GB RAM and not release any. Why? I have to shutdown WSL after copy a big file?

Answer:

Very normal but annoying issue. ... The only solutions are:

a) a kernel change by MS to limit the amount WSL2 can cache b) disable to caching ( nocache ) c) Put a limit on the WSL hyper-v VM

Not sure what or how MS will try to solve this issue... WSL1 did not have this issue, because it shared the main system memory, because it was just a layer around the NT kernel."

Re: Windows Subsystem for Linux: The lost potential

#202

Post by unnouinceput »

Quote:"...or, god forbid, suffer through the ancient CMD.EXE console". What's wrong with cmd.exe? It's a good tool

Quote: "and the fact that WSL continues to be separate from the native Windows environment shows. Even though I was quite hopeful, I cannot use WSL as my daily driver because I need to interact with “native” Windows tooling." You do know CygWin exists, yes? Quite good and get this, exists from the moment Win95 came to existence.

Re: Windows Subsystem for Linux: The lost potential

#203

Post by for_xyz »

mehrdadn wrote: post #189
acqq wrote: post #187

Earlier quoted context omitted.

NTFS on Windows was indeed always significantly slower when doing a lot of file operations. It was noticeable even long before WSL existed: NTFS and the whole infrastructure connected to it has by design bigger maintenance cost for every opening of the file, for example. That's undeniable. One can say that NTFS could have maybe been implemented faster on some other system (with less hooks etc), but NTFS on Windows is…

Again: try your operations on another file system, then tell me it's NTFS that's slow. It's not NTFS that's slow at opening files. It's the I/O subsystem. You'll see the slowness with other file systems too.

This is the correct answer. Myth that NTFS is slow should already go away.

You can already run windows on top of BTRFS if you want but it'll be painfully slow compared to linux [1].

https://twitter.com/NTDEV_/status/1327358814891470850 https://github.com/maharmstone/quibble

Re: Windows Subsystem for Linux: The lost potential

#204

Post by for_xyz »

unnouinceput wrote: post #202

Quote:"...or, god forbid, suffer through the ancient CMD.EXE console". What's wrong with cmd.exe? It's a good tool Quote: "and the fact that WSL continues to be separate from the native Windows environment shows. Even though I was quite hopeful, I cannot use WSL as my daily driver because I need to interact with “native” Windows tooling." You do know CygWin exists, yes? Quite good and get this, exists from the moment…

It's possible to interact with native windows tooling from WSL.

Example: $ echo "test" > test.txt & notepad.exe test.txt

Re: Windows Subsystem for Linux: The lost potential

#206

Post by eitland »

jmnicolas wrote: post #182
for_xyz wrote: post #179

Earlier quoted context omitted.

> the bottleneck is that NTFS is a crappy filesystem. Care to explain why do you think NTFS is crap? From my experience it's usually bad assumptions about files under windows and every application or library tries to stick to posix interface when dealing with files (open, read/write, close) which tends to block for longer periods on windows than on linux counterparts which results in significant perfomance loss . Lin…

> Care to explain why do you think NTFS is crap? I don't know if it's crap but it's much much slower than EXT4. I remember reading a comment here that Windows in a VM on a Linux host was faster than bare metal. Probably not true but I decided to make a test. I have a .net core app that insert data in a sqlite db (the resulting db is about 300 GB). So I benchmarked this app on Linux (it was previously running on Windo…

An interesting observation I did was that even Hello World is about 100x faster on Linux than on Windows.

In my Linux VM I had to use the time command to even have an idea of how long it took, as it seemed to return immediately. I think 5-15ms but it already a while ago.

On the Windows machine where the Linux VM ran it took several hundred ms.

Re: Windows Subsystem for Linux: The lost potential

#207

Post by acqq »

for_xyz wrote: post #203
mehrdadn wrote: post #189

Earlier quoted context omitted.

Again: try your operations on another file system, then tell me it's NTFS that's slow. It's not NTFS that's slow at opening files. It's the I/O subsystem. You'll see the slowness with other file systems too.

This is the correct answer. Myth that NTFS is slow should already go away. You can already run windows on top of BTRFS if you want but it'll be painfully slow compared to linux [1]. https://twitter.com/NTDEV_/status/1327358814891470850 https://github.com/maharmstone/quibble

Note: I've explicitly said: "NTFS on Windows" and "NTFS and the whole infrastructure connected to it". Also: "NTFS was slower than FAT" was true for years. I have no experience with BTRFS, but that doesn't prove anything without knowing more details (the overhead introduced to make it work). So... it's both NTFS and the Windows "subsystems."

Re: Windows Subsystem for Linux: The lost potential

#208

Post by spacenick88 »

userbinator wrote: post #149
jhallenworld wrote: post #109

Earlier quoted context omitted.

I was wondering if Wine on Ubuntu is faster than Windows native. I found this OSBench near the end of this page (look for "Test:Create Files"): https://www.phoronix.com/scan.php?page=article&item=wine-ubu... Ubuntu native is much faster. It's odd that Wine is so slow.. I wonder why?

Linux and Unix in general seems to love huge writeback caching, which is great for speed but horrible for consistency and reliability to power failure and such; on the other hand, Windows flushes the caches more often, providing greater reliability but without as much speed. That's been my experience, in any case; doing lots of small file operations barely causes any disk activity in Linux, but far more in Windows. M…

Linux/Unix just trust that if you want something persisted with certainty you'll do an fsync, if you do it will absolutely guarantee you're not losing that. It will absolutely make sure that your filesystem doesn't get corrupted by a power loss but if you didn't fsync your write you had no place believing it was persisted.

Doing that IMHO matches real world use much better. If I do a compile and get a power outage I don't care if some object files get lost. If I do an INSERT in a DB I do care a lot but the DB knows that and will fsync before telling me it succeeded. So making sync explicit gives you both great performance and flexibility.

Re: Windows Subsystem for Linux: The lost potential

#209

Post by for_xyz »

m_mueller wrote: post #181
for_xyz wrote: post #179

Earlier quoted context omitted.

> the bottleneck is that NTFS is a crappy filesystem. Care to explain why do you think NTFS is crap? From my experience it's usually bad assumptions about files under windows and every application or library tries to stick to posix interface when dealing with files (open, read/write, close) which tends to block for longer periods on windows than on linux counterparts which results in significant perfomance loss . Lin…

so what's the 'Windows way' then? keeping a file open forever and let it lock out other programs from using that file? I'm starting to get an idea why Windows is getting on my nerves so much with file locks....

> so what's the 'Windows way' then?

Using either memory mapped files of overlapped io (IOCP).

It's tricky to use when you want to write the content since you must preallocate the file before you start with the writing. Appending to file just doesn't work under NT kernel since WriteFile blocks even if you use overlapped io.

Devs just need different mentality when it comes to Windows programming compared to Linux. Due the fact that everything under NT kernel is operated asynchronously you'll have to adapt your code to such concept. Meanwhile under Linux you had no other alternative for nearly 30 years (io_uring and friends) so if you wanted to be portable with minimum OS specific code then you had to implement things in synchronous way or write two separate code paths for each OS.

Guess which one is used in practice.

Re: Windows Subsystem for Linux: The lost potential

#210

Post by peteri »

Macha wrote: post #79
shawnz wrote: post #68

Earlier quoted context omitted.

It's clear that they are not enthusiastic about delivering new features to WSL1. Consider how WSL2 now exclusively features CUDA support, Wayland support, loop mounts, Docker, etc.

Docker support is precisely the sort of feature that would have required significantly more work to support in WSL1 than WSL2.

Docker works fine with WSL1, I don't think I can use WSL2 at work as we're waiting on the next LTS version of Windows.
Post reply on HN