Your feedback requested: Experimental parallel compile feature in Update 8

[Steven_L_Intel1]

Microsoft Visual C++ has a /MP feature where it can compile two or more sources in parallel, speeding build times. We have had many requests to add this for Fortran. Intel Visual Fortran Composer XE 2011 Update 8, available now from the Intel Registration Center, has an experimental version of support for this. To enable it, right click on a project in Visual Studio and select Properties. Go to the Fortran > Command Line property page and add, as the first (or only) option under "Additional Options",

/MP

It is important that this be the first option in this field or else it will not be recognized.

If this is done, the Fortran build system will compile multiple files in parallel if they have no unresolved dependencies. In this version, the dependence determination is simplistic and conservative, but for many large projects it should allow a quicker build on a multicore or multiprocessor system. Note that this is not the same as Visual Studio's ability to build multiple projects in parallel, which already works for Fortran.

The way you can tell it is working is to look at the build log and see if there are ifort commands with more than one source file specified.

Please try this and let us know if you see an improvement, or if you find problems. We plan to provide a normal property-page interface for this option in the future

[bmchenry]

WOW!
Tried the /MP option on a sample project with ~40 subroutines and ~11 modules.
w/o the option rebuild all times were 4:23, 4:40...
with the option rebuild all times were 1:33,1:36,1:34
Great savings in time (almost a factor of 3!)
in the build log for baseline was45 ifort commands
reduced to 2 ifort commands w/multiple files with the /MP command.

running on Lenovo W701ds win7 w/Intel i7 Q720@1.60GHz 1.6 GHz, 8 GB, 64-bit compiling for win32

[mecej4]

The /MP option (when used as the very first option as stipulated above) works fine when command line compilations are performed, as well. The speed-up is impressive, but a question: when Visual Studio is not used, there is no dependency check done automatically, and most makefiles are not set up to exploit the /MP option.

Furthermore, there is no guarantee that, with the command

ifort /MP f1.f f2.f f3.f ...

we may expect f1.f to be compiled before f2.f. If the compilation of f1.f produces a module file that is used by f2.f, there can be problems.

Perhaps, the user could request something similar to a "barrier" as in:

ifort /MP f1.f f2.f f3.f $ g1.f g2.f g3.f ...

The intent is to direct the compiler to check that any modules produced by f1, f2 and f3 have been fully output before the parallel compilation of g1, g2 ... is initiated. (It is probably not necessary to wait until the object files have been output. The $ separator signifies a compilation barrier.)

It is interesting that not only is the compilation with multiple cores faster, it causes the fan on my i7-2720 (Dell laptop) to turn on less often. There are many potential benefits that this new /MP option opens up.

Congratulations!

[Steven_L_Intel1]

Right - /MP does work from the command line, but it is then up to you to make sure there are no dependencies between the files. I don't think the placement matters there - the requirement on placement in VS is to give the VS integration an easy way to see that you have requested this option in lieu of adding a property, since this is still experimental. But the results are promising so far.

[jirina]

I am very happy - the functionality of /MP is perfect and the speedup is very pleasant.

I am running Windows 7 Professional 64-bit on HP ProBook 6550b with Intel i5 @ 2.40 GHz and 8 GB RAM; a complete rebuild of my application with about 750 subroutines and functions, done for 64-bit systems, took 200 seconds, while the /MP option reduced the rebuild time down to 95 seconds, so more than 50%.

The compiler options used are:
/nologo /fpp /fixed /extend_source:132 /Qopenmp /fpscomp:general /warn:declarations /warn:unused /warn:truncated_source /warn:noalignments /warn:interfaces /assume:byterecl /module:"x64\Release\" /object:"x64\Release\" /Fd"x64\Release\vc100.pdb" /libs:static /threads /c /MP

The linker options are:
/OUT:"x64\Release\MyApp.exe" /NOLOGO /DELAYLOAD:"x64.dll" /MANIFEST /MANIFESTFILE:"...\x64\Release\MyApp.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /SUBSYSTEM:CONSOLE /STACK:100000000 /IMPLIB:"...\x64\Release\MyApp.lib" delayimp.lib .\DLL\x64\x64.lib

Thank you very much for this enhancement!

[rase]

I had problems with the /MP option and the /warn:interfaces option, combined in one project. I received a nonsense error message which disappeared when I removed the /MP option again. The compiler referred to an old interface definition which was not longer valid and should have been replaced in the compile step - probably a rare coincidence. I use VS2010 and update 8, Windows 7-32; CPU is Intel i7-920 (4 cores).

[Jacob_Williams]

The /MP option works great for me. I'm compling a library with 1252 files. Previous compile time: 137 sec. New compile time: 23 sec (about 6 times faster). This is for a group of files with no interdependencies (all Fortran 77 subroutines and functions). In my main project of a couple hundred modules with complex interdependencies, I don't see as big an improvement.

[DavidWhite]

Steve,

My solution has 7 separate projects in it.

In release mode, 1:28 reduced to 0:42, but about 20 seconds of this was running NSIS as a post build event.
In debug mode, 0:48 reduced to 0:16

So both cases reduced the build time by about 2/3.

Regards,


David

[Steven_L_Intel1]

Thanks for all the feedback. It has been very helpful.

[jimdempseyatthecove]

Steve,

I haven't used this feature (yet), havem't worked in Fortran for a while now.

Can you comment on the impact, if any, on IPO?

Can you comment on the impact, if any, with respect to Link Time optimizations (i.e. the newer IPO in blended C/C++/Fortran/other)?

From the reports, it looks like a major improvement.

I like the earlier post of requesting a synchronization point token. If the token on the line is too much of a hack, can you add a !DEC$ DependsOn: file1, file2, ...

Something like that or !DEC$ MT BARRIER

Jim Dempsey

[Steven_L_Intel1]

Jim,

It has no impact on IPO. All it does is allow more sources to be compiled in parallel when there are no module dependencies, shortening total build time on a multicore or multiprocessor system.

I doubt we'll add much to this - perhaps more fine-grained analysis of when a file's dependencies have been satisfied. But what I'm seeing so far is that even the coarse analysis is a winner for many projects. I don't see us adding directives.

[mecej4]

Steve,

There is one place where the /MP option needs a little help. Many software packages come with makefiles to build them, and very often they are from the Unix world and the object file suffix is .o rather than .obj. Sometimes this is hard-wired into the GNU configure script (e.g., NetCDF) and can be tough to overcome.

Without the /MP option, the makefiles can be used without change by using the compiler option /Fo in the Make suffix rule:

.f90.o:
$(F90) $(F90FLAGS) /c $< /Fo$@

I don't see how to make this work with multi-thread compilation without being able to specify a non-default object file extension. For example, in analogy with the /extfor option, an /extobj option, if it became available, would be of great use with the /MP option.

Thanks.