ifort OpenMP overhead: Windows versus MacOSX

[Greynolds__Alan]

The performance of my ifort-compiled OpenMP application scales with number of threads better on Windows XP than MacOSX Leopard on exactly the same hardware. Does this mean that Windows threading model has inherently less overhead than the MacOSX model? Or is ifort's OpenMP implementation on Windows more developed than its MacOSX version?

BTW, I'm still using 10.1.030 on Windows XP because of "random" flakiness in 11.x. There was a switch there from the"Guide" threaded libraries to MS ones.

Al Greynolds
www.ruda.com

[TimP]

Quoting - AlGreynolds

BTW, I'm still using 10.1.030 on Windows XP because of "random" flakiness in 11.x. There was a switch there from the"Guide" threaded libraries to MS ones.

Do you mean the change from default /Qopenmp-lib:legacy to /Qopenmp-lib:compat ? One of the reasons for the command line switch is so that you could isolate whether a problem is associated with the choice of OpenMP library.
ifort doesn't use the vcomp, although we have seen it come in accidentally in mixed C/Fortran builds along with the ifort legacy library. Any combination of more than one version of any of libguide, libiomp5, or vcomp, static or dynamic, is a problem. If you have a particular version of libguide fixed somewhere in your build, any change of library elsewhere could be a problem. Partial static linking of one library, followed by linking another static or dynamic version elsewhere, is particularly to be avoided.
vcomp apparently hasn't seen updates since VS2005; my experience upholds my colleagues' recommendation to use (just one version of) libiomp5 exclusively.
If you can show a bug in a current version of libiomp5, please submit it on premier.intel.com.

[Greynolds__Alan]

Quoting - tim18

f you can show a bug in a current version of libiomp5, please submit it on premier.intel.com.

Actually, the "flakiness" in 11.x I mentioned probably has nothing to do with OpenMP. My application runs fine with "debug" settings but crashes or generates NaNs with "full" optimizations. This is not a problem in 10.1.030 (using exactly the same command line options) and with any of the half-dozen other optimizing Fortran compilers I use. It could well be some inadvertently ambiguous code of mine, but I just haven't had time to isolate the cause and submit a bug report. On the other hand I have seen these kind of problems creep into IVF before with each major release. IMHO, Intel appears to be too ambitious with new features, sometimes at the expense of robustness. I still marvel at how robust my 4 year old XLF and LF95 compilers are.

I would still like to understand the differences I see between the Windows and MacOSX OpenMP implementations that was the MAIN subject of my original post.

Al