- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
we use Microsoft Visual C++ 2008 in a large project consisting of Fortran and C/C++ code.
Fortran compiler/runtime Version: 10.1.025
Enabling parallel builds not only on file level but also on solution (.sln) level, results in errors that
we don't face when parallel building is disabled on solution stage.
Howto enable parallel builds solution-wise:
Visual-Studio Menu -> Tools -> Options -> Projects and Solutions -> Build and Run -> maximum number of parallel project builds -> ${NUM} > 1
We are experiencing no problems whatsoever with C/C++ based projects.
As far as Fortran projects are concerned, the compiler seems to somehow 'lock' fortran include files (.inc files)
letting another ifort.exe process fail to access the include files as well.
Typical error message: "XYZ.f(630) : Error: Cannot open include file 'ABC.inc'"
Any hints are welcome.
Regards,
Babak Sayyid Hosseini
we use Microsoft Visual C++ 2008 in a large project consisting of Fortran and C/C++ code.
Fortran compiler/runtime Version: 10.1.025
Enabling parallel builds not only on file level but also on solution (.sln) level, results in errors that
we don't face when parallel building is disabled on solution stage.
Howto enable parallel builds solution-wise:
Visual-Studio Menu -> Tools -> Options -> Projects and Solutions -> Build and Run -> maximum number of parallel project builds -> ${NUM} > 1
We are experiencing no problems whatsoever with C/C++ based projects.
As far as Fortran projects are concerned, the compiler seems to somehow 'lock' fortran include files (.inc files)
letting another ifort.exe process fail to access the include files as well.
Typical error message: "XYZ.f(630) : Error: Cannot open include file 'ABC.inc'"
Any hints are welcome.
Regards,
Babak Sayyid Hosseini
Link Copied
3 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Babak,
Intel will have to answer this, but I agree with you that the source files should be opened with shared read. If the files are preprocessed, then there is the additional issue as to if each thread creates its own set of temp files, or if the files are preprocessed once and same temp files are then shared.
I seem to recall this problem reported back in IVF8.n or 9.n days.
There is another issue where you may have to carefully structure the solution build with respect to the module dependencies. A module build creates not only a "precompiled header" so to speak, but also creates .obj files. If you are not careful you can at times produce circular dependencies.
Jim Dempsey
Intel will have to answer this, but I agree with you that the source files should be opened with shared read. If the files are preprocessed, then there is the additional issue as to if each thread creates its own set of temp files, or if the files are preprocessed once and same temp files are then shared.
I seem to recall this problem reported back in IVF8.n or 9.n days.
There is another issue where you may have to carefully structure the solution build with respect to the module dependencies. A module build creates not only a "precompiled header" so to speak, but also creates .obj files. If you are not careful you can at times produce circular dependencies.
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Jim,
thank you for your response.
Each ifort.exe process/thread needs only a read-only access to the fortran include files.
There should be no need to exclusively lock a fortran include file.
As the error messages indicate the inability to open the includes though, we assume a kind of exclusive lock
or an other type of 'restrictive' access to those files in case multiple processes/threads are trying to read
the same files.
The error is very annoying as we could significantly reduce the build time on a multi-core machine, would the above
described issue be absent.
Anyway, let's hope someone experienced the same problems and can elaborate on the topic.
P.S.
The same errors are not always reproducible as the set of fortran include files which couldn't be open varies.
We have also faced cases, where there are no errors at all.
This non-deterministic behaviour points to some race conditions.
Any hints aimed at solving the problem are welcome.
Regards,
Babak Sayyid Hosseini
"History of Flame Wars The first true flame warrior was the Roman statesman Cicero, who wrote various insulting letters to other Romans in the provinces. A classic example is this missive to Marc Antony: Marce! Ede stercem meum et morere! (Marcus! Eat my **** and die!) To this, Marc Antony replied: Cicero! Noli dicere!!! Malus vir es et crassus! (Cicero! Don't say that! You are a bad man, and you're fat) "
thank you for your response.
Each ifort.exe process/thread needs only a read-only access to the fortran include files.
There should be no need to exclusively lock a fortran include file.
As the error messages indicate the inability to open the includes though, we assume a kind of exclusive lock
or an other type of 'restrictive' access to those files in case multiple processes/threads are trying to read
the same files.
The error is very annoying as we could significantly reduce the build time on a multi-core machine, would the above
described issue be absent.
Anyway, let's hope someone experienced the same problems and can elaborate on the topic.
P.S.
The same errors are not always reproducible as the set of fortran include files which couldn't be open varies.
We have also faced cases, where there are no errors at all.
This non-deterministic behaviour points to some race conditions.
Any hints aimed at solving the problem are welcome.
Regards,
Babak Sayyid Hosseini
"History of Flame Wars The first true flame warrior was the Roman statesman Cicero, who wrote various insulting letters to other Romans in the provinces. A classic example is this missive to Marc Antony: Marce! Ede stercem meum et morere! (Marcus! Eat my **** and die!) To this, Marc Antony replied: Cicero! Noli dicere!!! Malus vir es et crassus! (Cicero! Don't say that! You are a bad man, and you're fat) "
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I recall seeing reports of this in older versions but not recently. Please try a newer version (12.0 is current.)
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page