IVF 10.1 & openMP question

[maria]

Hi,

I started to learn openMP. I was able to compile a simple program like matrix multiplication. The performance is exactly as I expected from openMP. I have IVF 10.1 professional version.

However, I run into the problem when I apply openMP to a large do loop in our application. The first problem is that there is no performance improvement at all . The secondproblemis that I can not use runtime library.

Here is what I experienced. When Iuse '!$OMP parallel do'before a do loop, the build output states that ' ...... remark: openMP defined loop was parallelized.' The clock time for the same time is the same as the serial run before. CPU time was double since I have dual processors. This means that there is not performance improvement at all.

When I added call to openMP runtime library,I got the error message when I build thesame application. The error messages are listed in the followings if 'omp_get_thread_num()' is added.
'1 error LNK2005: _invoke_watson already defined in MSVCRT.lib LIBCMT.lib (MSVCR80.dll)
'2 error LNK 2005: _smsg_exit already defined in MSVCRT.lib LIBCMT.lib (MSVCR80.dll)
3 error LNK ......................................................................................
.....
18 error LNK 2005: _set_app_type already defined in MSVCRT.lib LIBCMT.lib (MSVCR80.dll)
21 fatal error LNK 1169: one or more multiply defined symbols found wamit.exe

Idid not list the lines between 3 - 18. These are the same as the line 1 & 2 but with different symbols.
What caused this? When I compile, I go to project properties, configuration (release), Fortran->Language
->process openMP directives (generate parallel code (/QopenMP)). For this application, I have two dynamic libaries.
The parallel part is applied in the main program.I only have problem with thisapplication. For the simple matrix multiplication code, I had no problem to call openMP run time library.

Thank you so much for considering my problems.

[jimdempseyatthecove]

In the project properties, linker page, try setting Ignore Specific Library to include LIBCMT.LIB (i.e. to ignore this library).

Jim Dempsey

[maria]

Quoting - jimdempseyatthecove

In the project properties, linker page, try setting Ignore Specific Library to include LIBCMT.LIB (i.e. to ignore this library).

Jim Dempsey

That works. Thanks. But just curious, why should I do this?

[TimP]

Quoting - maria

That works. Thanks. But just curious, why should I do this?

It may be a simpler work-around to avoid upgrades, either by applying VS2005 SP1 (or other appropriate service pack, if you aren't using a VS2005 variant), or upgrading to a current version of ifort with VS2008 shell, if you are using the PPE support for the Microsoft libraries. I'm hoping we will get confirmation; requirement for such a work-around clearly is undesirable.

[Steven_L_Intel1]

I consider use of "ignore library" a measure of last resort. Typically, one sees this sort of error when mixing Fortran and C++ code with different settings for the run-time library. In the case of using the OpenMP library and 10.1, if you have specified that your Fortran code is linking to the DLL libraries and you link to the static OpenMP library libguide.lib, you may run into this problem. Keep the library types consistent - use the DLL form of the OpenMP libraries.

[jimdempseyatthecove]

The underlaying problem is othewise known as"DLL Hell V2.0". The same named function is placed, or at one time was placed, in two different libraries (in maria's case it is in both libraries). The compiler or IDE then too "helps" the user to avoid specifying default libraries and automatically includes libraries it thinks/thought or may have been at one time, the right library (as opposed to requiring the programmer to specify the correct library). Then this problem (disruption) propigates further with this manifest mess, which for many (most?) circumstance is good, but when its bad, its very bad.

It seems to be very difficult to have a function call (subroutine) to a standardized name, using a standard conforming set of arguments, and then let the system go through a pecking order of DLLs to locate the first containing the match. The system should have a default pecking order (like PATH but using DLLs) and an app should have a means to specify a preferred or absolute requirement (by way of manifest or embedded comments/directives). Then the Linker should be able to resolve the difference although in some cases it might not resolve in the manner intended (but could emit warning to the effect).

Jim Dempsey

[maria]

Quoting - Steve Lionel (Intel)

I consider use of "ignore library" a measure of last resort. Typically, one sees this sort of error when mixing Fortran and C++ code with different settings for the run-time library. In the case of using the OpenMP library and 10.1, if you have specified that your Fortran code is linking to the DLL libraries and you link to the static OpenMP library libguide.lib, you may run into this problem. Keep the library types consistent - use the DLL form of the OpenMP libraries.

Sorry that I don't have much experience in compiler. For our program, we compile two dynamic linked libraries (these are written in Fortran). We then include these two libaries inmain project Resource files. In addition, we also includedone more libarary provided by another company, which is written in C. To compile, we add '/iface:cvf' in mainprojectand two dynamic library projects we build, fromproperty -> configuration properties-> fortran-> command line. My question is how to keep library types consistent in my case.
Please give me detailed instruction in my case.

One more question, I have deferred shape arrays in my code, which is not permitted in an openMP firstprivate & last
private. What should I for these arrays. We don't want to change the array type.

Thank you much.

[Steven_L_Intel1]

To answer your first question - in the executable project, go to the project properties and select Fortran > Libraries. Change "Runtime Library" to "Multithread DLL".

I'll have to leave your question about deferred-shape arrays to someone else.

[maria]

Quoting - Steve Lionel (Intel)

To answer your first question - in the executable project, go to the project properties and select Fortran > Libraries. Change "Runtime Library" to "Multithread DLL".

I'll have to leave your question about deferred-shape arrays to someone else.

Yes. We have 'Multithread Dll' in runtime library. What else should I do?

[Steven_L_Intel1]

If that's what you have in this project, then you are linking in an object or static library that was built with the "Multithreaded" (not DLL) setting. You need to find that. The DLL import libraries won't have this issue.

[maria]

Quoting - Steve Lionel (Intel)

If that's what you have in this project, then you are linking in an object or static library that was built with the "Multithreaded" (not DLL) setting. You need to find that. The DLL import libraries won't have this issue.

Our two dynamic-link libraries were bulit with Multithread DLL actually ('Multithread DLL (libs:dll/threads'). Our libararyis dynamic-link library, not static libary as your mentioned.Can this cause any problem? In addition, we also link a library builtby another company. I believe that their code was written in C++. Does this cause any problems?

[Steven_L_Intel1]

It is almost certainly the other company's library that is doing this to you. Does using the "Ignore library" for libcmt.lib help you there?

[maria]

Quoting - Steve Lionel (Intel)

It is almost certainly the other company's library that is doing this to you. Does using the "Ignore library" for libcmt.lib help you there?

'ignore library' for libcmt.lin do help me and I do not see the error message anymore. I got the reply from the other company about their dll , and their answer " ...is a mixture of C and Fortran, and (probably) is compiled
with Visual Studio 6.0; I don't think we have ever moved it to Visual Studio 2005." Any advise?

[Steven_L_Intel1]

If the other company's library is a DLL, that's not a problem. It's only static libraries that are the issue.

If you open the project properties and change the Linker > Progress Messages property to "show all progress messages", the build log will show where it gets the various default library directives from. If you search this for "libcmt.lib" you should be able to identify which object module or library is pulling this in.

[maria]

Quoting - Steve Lionel (Intel)

If the other company's library is a DLL, that's not a problem. It's only static libraries that are the issue.

If you open the project properties and change the Linker > Progress Messages property to "show all progress messages", the build log will show where it gets the various default library directives from. If you search this for "libcmt.lib" you should be able to identify which object module or library is pulling this in.

I did what you suggescted. Then I have no clue of how to identify. I attached the buildlog filehere. I know it's a long list. I would appreciate it very much if you can read it. Thanks again.

[Steven_L_Intel1]

Thanks - I find the output puzzling, as it seems to suggest that the reference to libcmt.lib is coming from libguide40.lib, which does not seem possible. At this point, just go with the "ignore libcmt.lib" and move on.