Introduction

The motorBike case is part of the tutorials that come with OpenFOAM 1.6. This particular version of the case uses the bug fixes posted in the OpenFOAM 1.6.x git version. These are the timing results of using the original version of OpenFOAM and the cross-compiled version.

The set-up:

• The tests that were performed were a single run with each available version of OpenFOAM, all executed in computers with 4GiB of RAM and have Intel Core2Duo E8400 @3.00GHz.

• The Linux versions of OpenFOAM 1.6 used are the ones available here (32bit) and here (64bit); both versions were executed in OpenSUSE 10.3 x86_64.

• The Windows versions of OpenFOAM 1.6 were cross-compiled with mingw and mingw-w64, available with blueCFD.

• The MPI cases were run with dual-core single-machine, with the mesh split in two on the Y axis, thus splitting the bike symmetrically.

• The mesh and results are compressed with gzip internally (default of the case).

Run times:

The times are in seconds and the results are in the following table:

Legend:

• the version mingw32 is cross-compiled with gcc-4.3.3 mingw;
• the versions mingw-w32 and mingw-w64 are cross-compiled with gcc-4.4.2 mingw-w64;
• SP means Single Precision;
• DP means Double Precision.

Notes:

• snappyHexMesh returns two timings: write mesh time and total execution time. These timings reflect the weight that writing the meshes has in the whole process of generating the mesh.

• The meshes for each run with simpleFoam were generated by the respective version of snappyHexMesh, therefore the results are subjective to the generated mesh. In other words, the mesh for each run isn't the same.

• These timings are of a single run for each version. Proper testing should have at least 5 runs to do an average.

• The mingw-w32 SP version of snappyHexMesh isn't always able to produce a working mesh, due to floating point issues.

Conclusions:

The cross-compiled versions suffer from the conversion layer of using the mingw run-time. Therefore file handling isn't optimized as a result and also dedicated core optimizations were not used (e.g. mmx and sse). Memory allocation may also suffer from insufficient optimization by gcc for Windows, although the -O3 switch was used.
Nonetheless, the mingw-w64 version of snappyHexMesh has surprising timing results, reaching execution speeds near to those in Linux.

Be first to comment this article

Write Comment

Please keep the topic of messages relevant to the subject of the article. Personal verbal attacks will be deleted. Please don't use comments to plug your web site. Such material will be removed. If you can't read the security code, click on the image to generate a new one!
Name:
E-mail
Homepage
Title:
BBCode:
Comment:
Code:*
	I wish to be contacted by email regarding additional comments

Powered by AkoComment Tweaked Special Edition v.1.4.6
Captchas Security update made by blueCAPE, based on www.thecaptchas.com
AkoComment © Copyright 2004 by Arthur Konze - www.mamboportal.com
All right reserved