Transition Windows usage to WSL

[Lestropie]

Follows recent #2536.

Related to forum Wiki page.

I've not long ago upgraded to Windows 11 on my home PC, but only today did I try getting mrview working in WSL, and it was relatively seamless. So as has been discussed on multiple occasions, it's potentially time now to transition the Windows installation instructions to be based on WSL.

• Determine minimum requirements for WSL with GUI
  (in earlier discussions it was suggested that this would only be available for Windows 11, but some pages I've read suggest that the latest solution can work on Windows 10 as well)
• Test flagging WSL2 mount of OS drives as networked and therefore to use delayed write-back
• Test whether extracting pre-compiled Linux binaries works in WSL
  (I've only tested building from source)
• Test relative performance of MSYS2 vs. WSL
  Have already done some of this in comments below; but eg. copying between OS drive mounts and Linux native drive may be insightful w.r.t. read vs. write performance
• Contemplate full deprecation of MSYS2
  • May depend on result of investigation above
  • Test whether removing zero-padding of output image reduces stall at commencement of processing where delayed write-back is not used (happens within ftruncate()?)
  • Test processing speed of tractography in case where image in disk has appropriate strides and therefore input image is memory-mapped (in case there is a penalty to caching)
    (Possible solution would be that if input image is on Plan9 FS, explicitly load the image data into RAM upon a .with_direct_io() request, even if the strides are already correct)
• Modify software documentation to reflect alternative installation instructions
• Add banner to forum Wiki page indicating change in capabilities, linking to new instructions, and that the trailing information is there for historical reference only
  (and some of the historical text there may need to be edited to refine statements that are outright no longer true)
• Consider adding replies to multiple community forum threads discussing the prospect of using WSL for MRtrix3, so that anyone coming across those threads is directed to the up-to-date instructions

[bjeurissen]

If it works on windows 10, I am definitely in favor of this.

Did you get a chance of benchmarking some commands on WSL against msys?

[Lestropie]

Good idea RE benchmarking.

mrview opening speed looks comparable. MSMT looks comparable, at least as far as the processing itself is concerned.

Seems to be a big difference in disk access. mrconvert-ing a DWI series from +1,+2,+3,+4 to +2,+3,+4,+1 with -nthreads 0 is 1s on MSYS2, 15s on WSL. Both input and output are memory-mapped in both cases, and at the same filesystem location. Moving the files into the WSL internal storage yields comparable performance. Apparently this is a known performance issue with WSL2 accessing OS drives. Theoretically you can just keep any project files within the WSL Linux storage, and those files can even be navigated to directly within File Explorer; but it's undoubtedly a performance issue that would be reported many times.

[jdtournier]

If it works on windows 10, I am definitely in favor of this.

It won't and Microsoft don't have any plans to back-port their Wayland server back to Windows 10. This is the main reason I've not been able to test this until recently, when I finally upgraded my laptop to Windows 11.

Performance-wise, when I looked into this a year or two ago, I got about 2× better performance with WSL2 for CPU-intensive workloads. It was definitely faster. Haven't looked into it for a while though.

IO workloads don't fare so well, because WSL2 is essentially a VM, and access to OS drives is basically via a network protocol (on my system, mount reports using drvfs with FS type 9p, which as far as I can tell, is the Plan 9 network protocol). We may get better performance by adding that to the list of FS types detected as network types, which would trigger delayed write-back and hopefully help with performance on that front ­­­– assuming it's not already detected as such... We'd just need to figure out the correct FS type ID and add it to the list...

[Lestropie]

Microsoft don't have any plans to back-port their Wayland server back to Windows 10

I know you'd stated this as having been the case previously; but looking through the various pages I was reading after following #2536 I had the impression that the situation may have changed. I'd need to go back and grab some actual citations. Think it has to do with this "WSLg" thing, which I'd never heard of until yesterday.

We may get better performance by adding that to the list of FS types detected as network types

Good idea; I've added to the checkbox list.

[jdtournier]

OK, I had another look just to check, and I may have been wrong about that. According to the WSLg README, it will now run on Windows 10 as well! If anyone still has a Windows 10 system, it would be great to have this confirmed.

[Lestropie]

Using delayed write-back (fsbuf.f_type == 0x1021997) reduces the test operation above from 15s to 5s. So clearly residual performance penalty in read.

[Lestropie]

Plan 9 performance may receive a boost in the not too distant future, which would deprecate a number of the concerns raised here: https://www.phoronix.com/news/Linux-9p-10x-Performance

[Lestropie]

As a ping update, I recently tested Ubuntu 24.04 WSL on up-to-date Windows 11, and IO-bound performance to host OS mount is still noticeably slower than MSYS2. Faster by adding 9P to list of network file systems (0x1021997), but doesn't bridge the gap.