Running a simulation on pure Ubuntu vs on Ubuntu in Windows (WSL)
Clash Royale CLAN TAG#URR8PPP up vote
14
down vote
favorite
I would like to ask a question about testing a large CAE simulation on the same computer in the following two situations.
- Pure Ubuntu system
- Ubuntu system in Windows 10 (WSL)
Are the calculation speeds in both cases almost the same or are they different?
windows windows-subsystem-for-linux benchmarks
edited May 13 at 16:30
Zanna
47.9k13119227
asked May 13 at 3:44
ABCDEMMM
8315
add a comment |Â
up vote
14
down vote
favorite
I would like to ask a question about testing a large CAE simulation on the same computer in the following two situations.
- Pure Ubuntu system
- Ubuntu system in Windows 10 (WSL)
Are the calculation speeds in both cases almost the same or are they different?
windows windows-subsystem-for-linux benchmarks
edited May 13 at 16:30
Zanna
47.9k13119227
asked May 13 at 3:44
ABCDEMMM
8315
4
Without knowing the nature of the simulation, this is impossible to answer.
– muru
May 13 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
May 13 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
May 13 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
May 13 at 9:06
@muru, it is a CAE Simulation (Abaqus CAE).
– ABCDEMMM
May 13 at 12:33
add a comment |Â
up vote
14
down vote
favorite
up vote
14
down vote
favorite
I would like to ask a question about testing a large CAE simulation on the same computer in the following two situations.
- Pure Ubuntu system
- Ubuntu system in Windows 10 (WSL)
Are the calculation speeds in both cases almost the same or are they different?
windows windows-subsystem-for-linux benchmarks
edited May 13 at 16:30
Zanna
47.9k13119227
asked May 13 at 3:44
ABCDEMMM
8315
I would like to ask a question about testing a large CAE simulation on the same computer in the following two situations.
- Pure Ubuntu system
- Ubuntu system in Windows 10 (WSL)
Are the calculation speeds in both cases almost the same or are they different?
windows windows-subsystem-for-linux benchmarks
edited May 13 at 16:30
Zanna
47.9k13119227
asked May 13 at 3:44
ABCDEMMM
8315
edited May 13 at 16:30
Zanna
47.9k13119227
edited May 13 at 16:30
Zanna
47.9k13119227
edited May 13 at 16:30
Zanna
47.9k13119227
47.9k13119227
asked May 13 at 3:44
ABCDEMMM
8315
asked May 13 at 3:44
ABCDEMMM
8315
asked May 13 at 3:44
ABCDEMMM
8315
8315
4
Without knowing the nature of the simulation, this is impossible to answer.
– muru
May 13 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
May 13 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
May 13 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
May 13 at 9:06
@muru, it is a CAE Simulation (Abaqus CAE).
– ABCDEMMM
May 13 at 12:33
add a comment |Â
4
Without knowing the nature of the simulation, this is impossible to answer.
– muru
May 13 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
May 13 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
May 13 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
May 13 at 9:06
@muru, it is a CAE Simulation (Abaqus CAE).
– ABCDEMMM
May 13 at 12:33
4
4
Without knowing the nature of the simulation, this is impossible to answer.
– muru
May 13 at 7:54
Without knowing the nature of the simulation, this is impossible to answer.
– muru
May 13 at 7:54
1
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
May 13 at 8:01
@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
May 13 at 8:01
3
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
May 13 at 8:05
@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
May 13 at 8:05
1
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
May 13 at 9:06
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
May 13 at 9:06
@muru, it is a CAE Simulation (Abaqus CAE).
– ABCDEMMM
May 13 at 12:33
@muru, it is a CAE Simulation (Abaqus CAE).
– ABCDEMMM
May 13 at 12:33
add a comment |Â
4 Answers
4
active
oldest
votes
up vote
17
down vote
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.
answered May 13 at 9:00
Ilmari Karonen
430211
Perhaps not just tuning parameters, but compiler options (e.g.-O3 -march=haswellor 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
May 14 at 1:01
add a comment |Â
up vote
11
down vote
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.
answered May 13 at 4:02
WinEunuuchs2Unix
35k758132
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
May 13 at 7:49
6
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
May 13 at 7:54
What do you mean by "Ubuntu in Linux"?
– Jon Bentley
May 13 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
May 13 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
May 13 at 15:04
 |Â
show 11 more comments
up vote
7
down vote
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.
answered May 13 at 4:07
JimDeadlock
1528
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
May 13 at 17:33
2
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
May 13 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 runpstreeorps auxw, it's obvious that all all processes are still alive. (Ortopand hit M to sort by memory consumption).
– Peter Cordes
May 14 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;systemddoesn't work like SysVinit. The earlier part of this comment is pretending that you were running a 5 or 10 year old Linux distro with an old-schoolinitsetup.) 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
May 14 at 1:11
1
@MichaelEricOberlin: Your comment is quite simply wrong. Would you please consider deleting it?
– Eric Duminil
May 14 at 11:56
 |Â
show 6 more comments
up vote
1
down vote
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).
answered May 14 at 9:07
Mehrdad
1,61182745
really good to know it!
– ABCDEMMM
May 14 at 9:13
add a comment |Â
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
17
down vote
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.
answered May 13 at 9:00
Ilmari Karonen
430211
Perhaps not just tuning parameters, but compiler options (e.g.-O3 -march=haswellor 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
May 14 at 1:01
add a comment |Â
up vote
17
down vote
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.
answered May 13 at 9:00
Ilmari Karonen
430211
Perhaps not just tuning parameters, but compiler options (e.g.-O3 -march=haswellor 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
May 14 at 1:01
add a comment |Â
up vote
17
down vote
up vote
17
down vote
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.
answered May 13 at 9:00
Ilmari Karonen
430211
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.
answered May 13 at 9:00
Ilmari Karonen
430211
edited May 13 at 10:21
answered May 13 at 9:00
Ilmari Karonen
430211
answered May 13 at 9:00
Ilmari Karonen
430211
answered May 13 at 9:00
Ilmari Karonen
430211
430211
Perhaps not just tuning parameters, but compiler options (e.g.-O3 -march=haswellor 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
May 14 at 1:01
add a comment |Â
Perhaps not just tuning parameters, but compiler options (e.g.-O3 -march=haswellor 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
May 14 at 1:01
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
May 14 at 1:01
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
May 14 at 1:01
add a comment |Â
up vote
11
down vote
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.
answered May 13 at 4:02
WinEunuuchs2Unix
35k758132
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
May 13 at 7:49
6
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
May 13 at 7:54
What do you mean by "Ubuntu in Linux"?
– Jon Bentley
May 13 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
May 13 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
May 13 at 15:04
 |Â
show 11 more comments
up vote
11
down vote
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.
answered May 13 at 4:02
WinEunuuchs2Unix
35k758132
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
May 13 at 7:49
6
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
May 13 at 7:54
What do you mean by "Ubuntu in Linux"?
– Jon Bentley
May 13 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
May 13 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
May 13 at 15:04
 |Â
show 11 more comments
up vote
11
down vote
up vote
11
down vote
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.
answered May 13 at 4:02
WinEunuuchs2Unix
35k758132
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.
answered May 13 at 4:02
WinEunuuchs2Unix
35k758132
edited May 13 at 17:56
answered May 13 at 4:02
WinEunuuchs2Unix
35k758132
answered May 13 at 4:02
WinEunuuchs2Unix
35k758132
answered May 13 at 4:02
WinEunuuchs2Unix
35k758132
35k758132
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
May 13 at 7:49
6
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
May 13 at 7:54
What do you mean by "Ubuntu in Linux"?
– Jon Bentley
May 13 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
May 13 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
May 13 at 15:04
 |Â
show 11 more comments
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
May 13 at 7:49
6
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
May 13 at 7:54
What do you mean by "Ubuntu in Linux"?
– Jon Bentley
May 13 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
May 13 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
May 13 at 15:04
8
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
May 13 at 7:49
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
May 13 at 7:49
6
6
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
May 13 at 7:54
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
May 13 at 7:54
What do you mean by "Ubuntu in Linux"?
– Jon Bentley
May 13 at 12:48
What do you mean by "Ubuntu in Linux"?
– Jon Bentley
May 13 at 12:48
3
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
May 13 at 14:47
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
May 13 at 14:47
2
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
May 13 at 15:04
@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
May 13 at 15:04
 |Â
show 11 more comments
up vote
7
down vote
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.
answered May 13 at 4:07
JimDeadlock
1528
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
May 13 at 17:33
2
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
May 13 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 runpstreeorps auxw, it's obvious that all all processes are still alive. (Ortopand hit M to sort by memory consumption).
– Peter Cordes
May 14 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;systemddoesn't work like SysVinit. The earlier part of this comment is pretending that you were running a 5 or 10 year old Linux distro with an old-schoolinitsetup.) 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
May 14 at 1:11
1
@MichaelEricOberlin: Your comment is quite simply wrong. Would you please consider deleting it?
– Eric Duminil
May 14 at 11:56
 |Â
show 6 more comments
up vote
7
down vote
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.
answered May 13 at 4:07
JimDeadlock
1528
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
May 13 at 17:33
2
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
May 13 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 runpstreeorps auxw, it's obvious that all all processes are still alive. (Ortopand hit M to sort by memory consumption).
– Peter Cordes
May 14 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;systemddoesn't work like SysVinit. The earlier part of this comment is pretending that you were running a 5 or 10 year old Linux distro with an old-schoolinitsetup.) 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
May 14 at 1:11
1
@MichaelEricOberlin: Your comment is quite simply wrong. Would you please consider deleting it?
– Eric Duminil
May 14 at 11:56
 |Â
show 6 more comments
up vote
7
down vote
up vote
7
down vote
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.
answered May 13 at 4:07
JimDeadlock
1528
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.
answered May 13 at 4:07
JimDeadlock
1528
answered May 13 at 4:07
JimDeadlock
1528
answered May 13 at 4:07
JimDeadlock
1528
answered May 13 at 4:07
JimDeadlock
1528
1528
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
May 13 at 17:33
2
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
May 13 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 runpstreeorps auxw, it's obvious that all all processes are still alive. (Ortopand hit M to sort by memory consumption).
– Peter Cordes
May 14 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;systemddoesn't work like SysVinit. The earlier part of this comment is pretending that you were running a 5 or 10 year old Linux distro with an old-schoolinitsetup.) 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
May 14 at 1:11
1
@MichaelEricOberlin: Your comment is quite simply wrong. Would you please consider deleting it?
– Eric Duminil
May 14 at 11:56
 |Â
show 6 more comments
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
May 13 at 17:33
2
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
May 13 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 runpstreeorps auxw, it's obvious that all all processes are still alive. (Ortopand hit M to sort by memory consumption).
– Peter Cordes
May 14 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;systemddoesn't work like SysVinit. The earlier part of this comment is pretending that you were running a 5 or 10 year old Linux distro with an old-schoolinitsetup.) 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
May 14 at 1:11
1
@MichaelEricOberlin: Your comment is quite simply wrong. Would you please consider deleting it?
– Eric Duminil
May 14 at 11:56
1
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
May 13 at 17:33
@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
May 13 at 17:33
2
2
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
May 13 at 17:43
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
May 13 at 17:43
1
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
May 14 at 1:07
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
May 14 at 1:07
2
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
May 14 at 1:11
@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
May 14 at 1:11
1
1
@MichaelEricOberlin: Your comment is quite simply wrong. Would you please consider deleting it?
– Eric Duminil
May 14 at 11:56
@MichaelEricOberlin: Your comment is quite simply wrong. Would you please consider deleting it?
– Eric Duminil
May 14 at 11:56
 |Â
show 6 more comments
up vote
1
down vote
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).
answered May 14 at 9:07
Mehrdad
1,61182745
really good to know it!
– ABCDEMMM
May 14 at 9:13
add a comment |Â
up vote
1
down vote
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).
answered May 14 at 9:07
Mehrdad
1,61182745
really good to know it!
– ABCDEMMM
May 14 at 9:13
add a comment |Â
up vote
1
down vote
up vote
1
down vote
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).
answered May 14 at 9:07
Mehrdad
1,61182745
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).
answered May 14 at 9:07
Mehrdad
1,61182745
answered May 14 at 9:07
Mehrdad
1,61182745
answered May 14 at 9:07
Mehrdad
1,61182745
answered May 14 at 9:07
Mehrdad
1,61182745
1,61182745
really good to know it!
– ABCDEMMM
May 14 at 9:13
add a comment |Â
really good to know it!
– ABCDEMMM
May 14 at 9:13
really good to know it!
– ABCDEMMM
May 14 at 9:13
really good to know it!
– ABCDEMMM
May 14 at 9:13
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1035568%2frunning-a-simulation-on-pure-ubuntu-vs-on-ubuntu-in-windows-wsl%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
4
Without knowing the nature of the simulation, this is impossible to answer.
– muru
May 13 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
May 13 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
May 13 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
May 13 at 9:06
@muru, it is a CAE Simulation (Abaqus CAE).
– ABCDEMMM
May 13 at 12:33