4 ms·

It's really not. With WSL2 the kernel runs in a VM, but user-space programs do not. As a result, CPU-bound programs suffer close to zero overhead compared to ru

It's really not. With WSL2 the kernel runs in a VM, but user-space programs do not. As a result, CPU-bound programs suffer close to zero overhead compared to running natively on linux. AFAIK, there's no way to achieve anything like this on macOS.

Sangeppato 6y ago
Do you have any source/documentation for this? I'd really like to read more about it, my understanding has always been that WSL2 was more or less a classic VM on a type-1 hypervisor (Hyper-V)
crumbshot 6y ago
That is not quite correct, it is in WSL1 that they are NT processes, with Linux syscall emulation. But in WSL2 the whole thing runs in a Hyper-V VM, with a customised Linux kernel (available via http://linux.microsoft.com http://linux.microsoft.com) to help with interoperability between WSL and Windows.
qalmakka 6y ago
You got it completely wrong. WSL1 was a system call translation layer, and everything worked directly on the Windows kernel, like Windows programs do under WINE. WSL2 is an standard Hyper-V virtual machine, no more no less, with a custom Linux kernel build and a ext4 root filesystem stored in a .vhdx image. Every process runs as a native Linux process under the Microsoft's Linux kernel, _inside_ the VM. What makes it more convenient than simply opening the Hyper-V manager and creating a VM is ease of installation, maintenance and integration with Windows (using the 9p protocol to allow file access).
- withinboredom 6y ago
  And you got it all wrong :p. It’s not a “standard Hyper-V virtual machine” you can’t make one from scratch.
  - qalmakka 6y ago
    With "standard Hyper-V virtual machine" I mean that's like every other VM, because it runs under its own instance of vmwp.exe, spawned by vmms.exe, like every other one you may have in the system.
    - withinboredom 6y ago
      Now I want to take those executables apart and see if it does any special handling.

Sangeppato 6y ago

Do you have any source/documentation for this? I'd really like to read more about it, my understanding has always been that WSL2 was more or less a classic VM on a type-1 hypervisor (Hyper-V)

crumbshot 6y ago

That is not quite correct, it is in WSL1 that they are NT processes, with Linux syscall emulation. But in WSL2 the whole thing runs in a Hyper-V VM, with a customised Linux kernel (available via http://linux.microsoft.com http://linux.microsoft.com) to help with interoperability between WSL and Windows.

qalmakka 6y ago

You got it completely wrong. WSL1 was a system call translation layer, and everything worked directly on the Windows kernel, like Windows programs do under WINE. WSL2 is an standard Hyper-V virtual machine, no more no less, with a custom Linux kernel build and a ext4 root filesystem stored in a .vhdx image. Every process runs as a native Linux process under the Microsoft's Linux kernel, _inside_ the VM. What makes it more convenient than simply opening the Hyper-V manager and creating a VM is ease of installation, maintenance and integration with Windows (using the 9p protocol to allow file access).

withinboredom 6y ago
And you got it all wrong :p. It’s not a “standard Hyper-V virtual machine” you can’t make one from scratch.
- qalmakka 6y ago
  With "standard Hyper-V virtual machine" I mean that's like every other VM, because it runs under its own instance of vmwp.exe, spawned by vmms.exe, like every other one you may have in the system.
  - withinboredom 6y ago
    Now I want to take those executables apart and see if it does any special handling.