Running a simulation on pure Ubuntu vs on Ubuntu in Windows (WSL)

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.}

Ubuntu in Windows (WSL - 2017 Fall Creators Update) is definitely slower than "Pure" Ubuntu in Linux environment.

For example screen painting takes many times longer in Windows 10 versus Ubuntu 16.04, ie you can actually see the cursor move in Windows 10:

It takes about 5 seconds for the WSL Bash splash screen to paint. By comparison it is about 1 1/2 seconds for the same splash screen in Ubuntu 16.04:

CPU Benchmarking

The first section shows how slow screen I/O is but what about CPU benchmarking?

From this Ask Ubuntu Q&A: CPU benchmarking utility for Linux, I ran tests on Ubuntu 16.04 on Linux and Windows. On Linux about 24 seconds on Windows 10 version 1709 about 31 seconds. Linux is 6 seconds faster or about 25% faster. However I just upgraded Windows 10 to version 1803 (Redstone 4 aka Spring Creators April 2018 update) and it took 24 seconds which is the same as Linux.

Ubuntu 16.04 on Linux

$ sysbench --test=cpu --cpu-max-prime=20000 run
sysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1

Doing CPU performance benchmark

Threads started!
Done.

Maximum prime number checked in CPU test: 20000


Test execution summary:
    total time:                          23.5065s
    total number of events:              10000
    total time taken by event execution: 23.5049
    per-request statistics:
         min:                                  2.13ms
         avg:                                  2.35ms
         max:                                  8.52ms
         approx.  95 percentile:               2.76ms

Threads fairness:
    events (avg/stddev):           10000.0000/0.00
    execution time (avg/stddev):   23.5049/0.00

Ubuntu 16.04 on Windows 10 build 1709

$ sysbench --test=cpu --cpu-max-prime=20000 run
sysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1

Doing CPU performance benchmark

Threads started!
Done.

Maximum prime number checked in CPU test: 20000


Test execution summary:
    total time:                          30.5350s
    total number of events:              10000
    total time taken by event execution: 30.5231
    per-request statistics:
         min:                                  2.37ms
         avg:                                  3.05ms
         max:                                  6.21ms
         approx.  95 percentile:               4.01ms

Threads fairness:
    events (avg/stddev):           10000.0000/0.00
    execution time (avg/stddev):   30.5231/0.00

Ubuntu 16.04 on Windows 10 build 1803

$ sysbench --test=cpu --cpu-max-prime=20000 run
sysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1

Doing CPU performance benchmark

Threads started!
Done.

Maximum prime number checked in CPU test: 20000


Test execution summary:
    total time:                          23.7223s
    total number of events:              10000
    total time taken by event execution: 23.7155
    per-request statistics:
         min:                                  2.21ms
         avg:                                  2.37ms
         max:                                  4.53ms
         approx.  95 percentile:               2.73ms

Threads fairness:
    events (avg/stddev):           10000.0000/0.00
    execution time (avg/stddev):   23.7155/0.00

NOTE: Windows 10 spring update for 2018 (dubbed Redstone 4) came out on May 9th (4 days ago) and I will be installing it soon to check out the improvements. No doubt there are many. One I know of that interests me is the ability to run cron jobs on startup. I need that for automatic daily backups to gmail.com.

NOTE 2: I've just installed Windows 10 Build 1803 (April 2018 Spring Creators Update AKA Redstone 4) and the screen painting is much much faster. It's now only 3 seconds instead of 5 seconds to display the Bash splash screen. The CPU benchmark is on par with Linux now.

Think about it - in WSL your computer is running the full graphical Windows system (which is a horrific resource hog in the first place) plus the Ubuntu subsystem. In native Ubuntu it's only running Ubuntu.

I don't know whether this will affect your simulation in particular, but it might:

WSL does NOT use RAM for shared memory! It uses the disk!

This means, if your simulation uses shared memory (think /dev/shm), it may be slow and/or wear out your storage device! And the performance penalty comes from several layers:

• The file system driver

• The storage driver

• The storage medium

But if it doesn't do this, then the performance should be similar to that on bare-metal Ubuntu (assuming no other I/O, as others have mentioned).