While we wait for WSL2

In this article, an erroneous WSL1 execution time was displayed during the period May 21 to June 14, 2019. I apologize for any inconvenience.

This Microsoft announcement is only 15 days old today (May 21, 2019). When I made plans for the performance study presented below, I did not know

1. what kind of results that I would obtain (for obvious reasons)
2. that my procedures and results were to a considerable extent heading towards obsolescence.

Proponents of GNU/Linux and Microsoft Windows unnecessarily fight each other

(read here for another story about unnecessary fighting). If you are a private owner of a computer running Microsoft Windows, you may dislike the thought that Microsoft can control your computer to a larger extent that you – as the owner – can (have you ever reflected upon the fact that your Windows computer is shameless enough to initially address its owner with the message "Welcome"?).

For reasons like this, you may as a private person prefer an operating system which guarantees you the "four freedoms". For a business owner, things look different. The willpower and ability of Microsoft to keep thousands of computer setups exactly the same are in that case your friend.

See the picture of friend- and foeships? GNU/Linux (including its many derivatives) makes sense to knowledgeable individuals, and Microsoft Windows makes sense to business owners.

Why, then, the headline adverb of "unnecessarily"? Because Microsoft has for the last decades strived to approach a "best of two worlds" state of affairs. Kudos to Microsoft for every advance in that direction. A possible outcome is that knowledgeable employees in big organizations may – to the benefit of the company – get access to a more powerful toolset than would otherwise be the case.

Open source software tends to "be married" to the GCC compilers

This I have learnt the hard way. More than one year ago, I succeeded in transferring the build recipes of the much recognized open source CAE package OpenFOAM to Microsoft Visual Studio. My intent was to build a truly native version of OpenFOAM for Windows.

Then I discovered a pitfall which totally stopped the show (and sent two months of work down the drain): The huge body of C++ coding which together forms OpenFOAM, features a pervasive use of nonstandard C++ constructs which Microsoft’s C++ compiler does not understand.

In the open source world there are no blame games. It’s just the way it is. But this state of affairs has consequences which I will attempt to illustrate in the following.

Ways to run GCC-compiled software on a Windows computer

You may instead of creating "truly native Windows executables" do one or more of the following:

1. Cross-compile and build on a GNU/Linux computer and create Windows executables using MinGW technology
2. Compile and build on a Windows computer using MinGW technology
3. Compile and build on a GNU/Linux computer and run the executables in Docker
4. Compile and build using a GNU/Linux image in Docker and run the executables in Docker, too
5. Compile and build using a GNU/Linux image in WSL and run the executables in WSL, too

For the performance study below, only options 3 and 5 were applied.

A digression: OpenFOAM flavors and the standard problem of the "Ahmed body"

It as an awkward and unfortunate fact that the powerful OpenFOAM package for flow analysis is today maintained in three different flavors:

1. foam-extend led by Hrvoje Jasak
2. ESI OpenCFD led by Fred Mendonca
3. CFD Direct led by Henry Weller

It definitely appears that three is no company at all… These versions are unfortunately not input-compatible. However, important code improvements are said to spread between the three main flavors by means of diffusion.

The "Ahmed body" is a classic flow analysis problem established in 1984 as a reference for studying the behavior of ground-based vehicles. In the version used for the performance study below, it was suggested to me by Dr. Eugene de Villiers of Engys Ltd..

Results of the performance study

Adjustable parameters of the Ahmed body problem at hand were set so that a well-behaved run would take about a quarter of an hour on Simxon’s 16 processor dual boot computer. The job only applies 12 of these processors in order to avoid unjust performance penalties associated with system operations. ESI OpenFOAM v1802 was built "on location" for the Ubuntu versions (including Docker), and corresponding precompiled binaries were used for the WSL version.

The runtimes quoted below apply for the central part of the simulation which features a fixed iteration count of 1000.

Native Ubuntu: 16 minutes and 6 seconds

Docker on Ubuntu: 16 minutes and 17 seconds

Docker on Windows: 31 minutes and 51 seconds

WSL (on Windows): 31 minutes and 49 seconds (has been erroneously quoted as 10 minutes shorter)

Conclusion

OpenFOAM runs best on an OS of the GNU/Linux type. The performance overhead for Docker on Ubuntu is insignificant.

If, by May 2019, you want to run ESI OpenFOAM on Windows, the precompiled binaries for WSL are a viable option. Docker on Windows, on the contrary, comes with an overhead of almost 100 %.

Note that all setups applied must necessarily have leveraged multiprocessing. If they hadn’t, the performance overhead values would have been much bigger.

One can expect the upcoming WSL version 2 to perform quite well.