Ubuntu – Ubuntu/ Windows Shared Folder (using WSL)

Updated 2020/02/18 to reflect changes introduced in WSL2

Hi! Microsoft PM working on WSL & Command Line here.

WSL allows you to run native, unmodified Linux ELF-64 binaries directly on Windows, and enables you to run your favorite Linux tools atop your Windows "host" OS.

WSL1 took an approach of adding a Linux syscall compatible layer at the top of the NT kernel, allowing Linux binaries to run atop NT, sharing the same underlying filesystem, networking, process list, etc. as the host OS.

The soon to be released WSL2, on the other hand, runs distros' binaries within Linux containers, atop a real Linux kernel, inside a lightweight VM that allocates only the RAM needed by the apps it runs, and then releases freed RAM back to the host OS. This provides 100% Linux compatibility, and allows your Linux tools to run with near native performance, and consumes minimum resources necessary from the host, ensuring your machine runs fast and smoothly.

Prior to WSL2, one could run the Docker client in WSL1, using it to drive Docker for Windows running atop Hyper-V on the local host, or to manage a remote Docker server. But one cannot run Docker Engine on WSL1 for many technical reasons.

However, you can do the same in Docker on WSL2, but you can also run the Docker Engine itself atop WSL if you prefer. This is, Docker's preferred and future path for running Docker on Windows desktop.

To learn more about WSL, review the videos & docs here: https://aka.ms/learnwsl

Your simulation software is most likely either CPU bound or memory bound. For such workloads, one would not except to see any significant difference between running the code on "bare metal" or inside WSL (or any other compatibility layer or VM that uses native execution), since in either case the OS is mostly just standing by while the simulation code runs directly on the CPU.

However, it's also possible that your simulation is at least partially I/O bound, and that's where differences may emerge. Apparently, WSL (currently) has a rather slow filesystem interface layer that can slow down disk I/O significantly.* That said, while disk I/O can be the major bottleneck for many kinds of bulk data processing tasks, a "simulation" usually should not be spending the majority of its time reading and writing files. If yours is, you may want to consider running it from a RAM disk (e.g. tmpfs on native** Linux) to avoid needless physical disk access.

In any case, the only way to be sure is to test your simulation in both environments and time how long it takes to run. Before doing that, however, you may want to take a look at existing benchmarks, like this WSL vs. Docker vs. VirtualBox vs. native Linux performance benchmark by Phoronix from February 2018, and examine the results for any tests that stress the same components of the system as your simulation does.

(FWIW, the Phoronix results seem to mostly match the general principles I outlined above, although there are a few notable oddities like VirtualBox apparently outperforming native Linux in a few I/O bound benchmarks, apparently due to its virtual disk not always immediately syncing data to the physical disk. One potentially relevant issue that I failed to note above is that the benchmarks show significant differences in multi-threaded OpenMP performance both between the different host environments and also between different Linux distros even when running on bare hardware. In hindsight, that's not too surprising, since threading and IPC is handled by the kernel. I'd guess that much of the difference between the distros there may come down to different runtime and/or compile time kernel tuning parameters.)

^{*) According to this MSDN blog post from 2016, there are actually two filesystem interface components in WSL: VolFs, which closely emulates native Linux filesystem semantics over NTFS and is used to mount e.g. / and /home, and DrvFs, which provides mostly Windows-like semantics and is used for accessing the host Windows drives via /mnt/c etc. If your software doesn't specifically require native Linux filesystem features like multiple hard links to the same file, configuring it to store its data files in a DrvFs folder may improve file access performance on WSL.}

^{**) According to this Reddit thread from May 2017, "tmpfs is currently emulated using disk" on WSL. Unless something has changed over the last year, this presumably means that using tmpfs on WSL gives no performance benefit over using a normal on-disk filesystem.}