17

I would like to ask a question about testing a large CAE simulation on the same computer in the following two situations.

  1. Pure Ubuntu system
  2. Ubuntu system in Windows 10 (WSL)

Are the calculation speeds in both cases almost the same or are they different?

Improve this question
5
  • 4
    Without knowing the nature of the simulation, this is impossible to answer.
    – muru
    Commented May 13, 2018 at 7:54
  • 1
    @muru: It's not that vague. A "simulation" is presumably a computationally intensive background job, which makes it either CPU or memory bound. (Disk or network I/O might also be a bottleneck, but that's something people writing such programs tend to avoid, and some modern simulation code may even use the GPU for parallel computation.) One could pretty easily write (or download) a benchmark that tests all these 2 to 5 possible bottlenecks, and check if there's any significant difference between WSL and native Ubuntu for any of them. I'd do it, but I don't have WSL (or Windows 10) available.
    – Ilmari Karonen
    Commented May 13, 2018 at 8:01
  • 3
    @IlmariKaronen "presumably". Depending on the data bring crunched, it could just as well be IO intensive even if CPU bound. And the rest of your comment is a pretty good reason for closing this - we have no idea of what possible combination of bottlenecks matters here.
    – muru
    Commented May 13, 2018 at 8:05
  • 1
    Well, I did post an answer, since it turns out that suitable benchmarks are already online. Obviously, I cannot say for sure whether the OP's specific simulation code will run slower on WSL or not; but in any case, an answer to that question is of no use to anyone but the OP anyway. What I can answer, based on the benchmarks, is what types of simulation code could reasonably be expected to have performance differences between WSL and native Linux.
    – Ilmari Karonen
    Commented May 13, 2018 at 9:06
  • @muru, it is a CAE Simulation (Abaqus CAE).
    – ABCDEMMM
    Commented May 13, 2018 at 12:33

4 Answers 4

Reset to default
20

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.

Improve this answer
1
  • Perhaps not just tuning parameters, but compiler options (e.g. -O3 -march=haswell or something. I don't know what Clear Linux actually uses to build their kernels, but perhaps BMI2 / popcnt / whatever could make a measurable difference in glibc and the kernel. (The kernel won't benefit from AVX, though, because the kernel avoids touching FPU registers except in specific code like the software-RAID5/6 error-correction data.)
    – Peter Cordes
    Commented May 14, 2018 at 1:01
12

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:

WSL bash startup.gif

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:

Ubuntu terminal splash.gif

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.

Improve this answer
19
  • 8
    Note that this is misleading - this doesn't distinguish I/O performance and other computational performance. WSL is known to be slow for I/O (see e.g., Phoronix benchmarks). That does not say anything about whether OP's calculations can be done just as fast in WSL.
    – muru
    Commented May 13, 2018 at 7:49
  • 7
    I'm honestly surprised that drawing the splash screen isn't effectively instant in both cases. Your computer is (presumably) happy to do far more complex screen updates in a few milliseconds e.g. when playing video. And the last time I saw a terminal as slow as in your first recording was in the early 90's, when dialing up a BBS on my 2400 bps modem.
    – Ilmari Karonen
    Commented May 13, 2018 at 7:54
  • What do you mean by "Ubuntu in Linux"?
    – Jon Bentley
    Commented May 13, 2018 at 12:48
  • 3
    Honestly, this kind of benchmark is completely useless for any kind of realistic program, as any benchmark that essentially measures the console painting speed. Either your program bottleneck is console I/O (which is notoriously slow even on Linux with most terminal emulators), or this isn't a reliable measure of anything useful.
    – Matteo Italia
    Commented May 13, 2018 at 14:47
  • 2
    @WinEunuuchs2Unix From what I can see, there's little compuation. but lots of I/O: fetching the weather from somewhere, reading the date and time, and printing it in a format, reading system information, etc. Anyway, have you ever used Abaqus? Simulation software like it or Ansys or Simulink are not screen I/O bound when running the actual simulation unless you force the simulation to be so. It's perfectly possible for these to show the just end results depending on the simulation done.
    – muru
    Commented May 13, 2018 at 15:04
7

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.

Improve this answer
11
  • 1
    @JimDeadlock I really don't think it kills the desktop, it just doesn't display it. Every gui app is still running in the background, aren't they?
    – Eric Duminil
    Commented May 13, 2018 at 17:33
  • 3
    The windows GUI consumes some memory, but not very much CPU use when not doing anything. I don't see why that would have any significant impact?
    – vidarlo
    Commented May 13, 2018 at 17:43
  • 1
    Switching the console over to a different VT doesn't kill any processes; @EricDuminil is correct . It may pause things that were using CPU time to do graphics updates, because the X server knows it's no longer being displayed (and thus may not waste any time on OpenGL processing or whatever). But if you run pstree or ps auxw, it's obvious that all all processes are still alive. (Or top and hit M to sort by memory consumption).
    – Peter Cordes
    Commented May 14, 2018 at 1:07
  • 2
    @MichaelEricOberlin: Changing to another VT doesn't affect the runlevel! It's just that text consoles are still available in a runlevel that starts GDM. (And BTW, runlevels are basically a thing of the past; systemd doesn't work like SysV init. The earlier part of this comment is pretending that you were running a 5 or 10 year old Linux distro with an old-school init setup.) But yes, logging out of your X session and stopping X11 / GDM will free up resources, especially if you have no swap space, or your desktop has crap that wakes up frequently even when "idle".
    – Peter Cordes
    Commented May 14, 2018 at 1:11
  • 1
    @MichaelEricOberlin: Your comment is quite simply wrong. Would you please consider deleting it?
    – Eric Duminil
    Commented May 14, 2018 at 11:56
1

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

Improve this answer
1
  • really good to know it!
    – ABCDEMMM
    Commented May 14, 2018 at 9:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .