Intel® C++ Compiler
Community support and assistance for creating C++ code that runs on platforms based on Intel® processors.
7956 Discussions

ICC problem with ipo option on linux

hwang1211
Beginner
657 Views
Hey guys

I'm using icc and ifort to compile a MPI library and running test programs on Redhat Linux OS (2.6.18).

If I use "-O3 -ipo -xT -no-prec-div" as CFLAGS and FFLAGS value, I will meet a problem: when my MPI program call gethostbyname() function in MPI_Init(), the program will exit. If I use "-O3 -xT -no-prec-div" as CFLAGS and FFLAGS value, I don't meet this problem, but the performance is bad on a 8 cores nehalem processor (compared with GNU compiler gcc and f77).

icc and ifort version information is below.

icc -V
Intel C Intel 64 Compiler Professional for applications running on Intel 64, Version 11.1 Build 20100203 Package ID: l_cproc_p_11.1.069
Copyright (C) 1985-2010 Intel Corporation. All rights reserved.

ifort -V
Intel Fortran Intel 64 Compiler Professional for applications running on Intel 64, Version 11.1 Build 20100203 Package ID: l_cprof_p_11.1.069
Copyright (C) 1985-2010 Intel Corporation. All rights reserved.

I'm wondering whether the xiar command results in this problem: xiar is a GNU version.

xiar -V
xiar: executing 'ar'
GNU ar 2.17.50.0.6-12.el5 20061020
Copyright 2005 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License. This program has absolutely no warranty.

Any feedback is appreciated!
0 Kudos
7 Replies
aazue
New Contributor I
657 Views
Hi
I think without relation with xiar have suffix Linux
Xiar,Xild allredy changed by team drive fronted icc to IPO
Same with LTO require some parameter added with build binutils
(gold) or other same side(GIMPLE,TRANS ext ....)

You have build MMPICH2-1.2.1p1 or MPICH2-1.3.1p1 or other ?

You can verify the file (dump) GNU side LTO trace if relation problem with this structure
but i have doubts.

Verify if you have not irqbalance that it work default.
Verify also if you have not default gateway (IPV4 IPV6) conflict to 2 card address.
With large machine you have it could be necessary you modify some parameter /pro/sys/net/ipv*/....
I have not same machine to my hand for help you better...
Regards
0 Kudos
TimP
Honored Contributor III
657 Views
Quoting hwang121

If I use "-O3 -ipo -xT -no-prec-div" as CFLAGS and FFLAGS value, I will meet a problem: when my MPI program call gethostbyname() function in MPI_Init(), the program will exit.

-xT is not a good option for Nehalem or other recent CPUs, but it's not likely to depress performance more than 10%. The default option, or SSE3 or SSE4.2 options would be preferable. You shouldn't need -no-prec-div for any CPU in current production (but it's already set for you; it would make more sense to turn that stuff off).
I don't want to comment on use of -ipo with MPI, which I've never seen done, particularly as it would be important to know exact MPI version, whether you built it yourself, if so, with which compilers. You can't mix Fortrans with MPI; the MPI Fortran library must be built with a Fortran compatible with the one you use, so you would have to change library builds with any change among g77, gfortran, and ifort. There's more freedom with the C libraries.
It's difficult to believe that g77 would produce exemplary results on x86_64, as it was no longer maintained when x86_64 first came along. If you used gfortran 4.4 or newer, I could believe you might get good results.
We would need to be privy to your profiling information (-pg may be sufficient) and the nature of the code which is slow, in order to comment on performance.
A few missed optimizations were fixed in the most recent ifort release, but we can't guess if that's relevant without more information.
0 Kudos
aazue
New Contributor I
657 Views
Hi
About council:
(or SSE3 or SSE4.2 options would be preferable)

I think to use same flags Mpi can be result more catastrophic if you call external with
group machine heterogeneous hardware.

Ipo that you having use is judicious. he have effect to modify object better form
(for reduce consumption and prevent the faults part source mounted wrong)(object better form)
is not systematic benefit result improve times,
(Ipo have also value benefit even with small number objects)
Remark: Sometimes build with Ipo or Lto can be result correct with false result but difference
if an part wrong when you working
program you have fault constant, not aleatory , sometime it work and sometime not work.
Ipo or Lto require without faults ,strict, difficult, but if passed , result sure ...
Generally problem Is not part removed fault same, is write sometimes here other threads .
Your problem can be rather side irq with 8 processor have your machine.
Make some test (bind side using taskset ) with affinity only 1 processor and compare several.
Regards


Added...
I not use fortran also with my bad level your language difficult to situate your (*)relation
Mpi & fortran , resulting I don't know if this document can help you

I'm using icc and ifort to compile (*)a,an,my,the,with ???) MPI library and running test programs on Redhat Linux OS (2.6.18).

Section Document (change) of GNU compiler 4.5.1
http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-flto-801
move to chapter flag -flto

Another feature of LTO is that it is possible to apply interprocedural optimizations
on files written in different languages.
This requires some support in the language front end. Currently, the C,
C++ and Fortran front ends are capable of emitting GIMPLE bytecodes,
so something like this should work

gcc -c -flto foo.c
g++ -c -flto bar.cc
gfortran -c -flto baz.f90
g++ -o myprog -flto -O3 foo.o bar.o baz.o -lgfortran

Notice that the final link is done with g++ to get the C++ runtime libraries and -lgfortran is added
to get the Fortran runtime libraries.
In general, when mixing languages in LTO mode, you should use the same link command used
when mixing languages in a regular (non-LTO) compilation.

This means that if your build process was mixing languages before, all you need to add is -flto to all
the compile and link commands.
etc .... read more ...

Regards


0 Kudos
hwang1211
Beginner
657 Views
Actually, I tried to use SSE4.2 option (on E5640), the performance is not good (compared with GCC). The MPI library I use is MVAPICH2-1.5 version; and the performance number is about osu micro benchmark.

Why -xT, -ipo and -no-prec-div options are considered: SPEC MPI results Intel submitted used -xT and -ipo options for E5462 processor and X5670 processors.

0 Kudos
hwang1211
Beginner
657 Views
This means that if your build process was mixing languages before, all you need to add is -flto to all
the compile and link commands.


Thanks! The problem I met looks like gethostbyname() library can't be found (missing symbol?). I will try -flto option.
0 Kudos
aazue
New Contributor I
657 Views
Hi
About:
This means that if your build process was mixing languages before, all you need to add is -flto to all the compile and link commands.
I think not obligated depend how is mounted ..
See about flag (-fuse-linker-plugin) if i remember with my old head...
But Important is you having solving your problem gethostbyname() library
Regards

0 Kudos
TimP
Honored Contributor III
657 Views
Getting -ipo or -flto to work should not be at the top of your priority list. You've taken on quite a challenge; focus on more important issues, including answering the question of whether you rebuilt the MPI Fortran library with the ifort you intend to use.
Did you get your job working with openmpi or Intel MPI before tackling the usually difficult mvapich2?
0 Kudos
Reply