[Beowulf] Intel compilers V8

[Chris Samuel]

On Fri, 16 Jul 2004 10:36 am, Serguei.Patchkovskii at sympatico.ca wrote:

> Unless your code is very similar to one of the SPEC benchmarks, 8.0 may
> also generate slower code, compared to ifc 7.1, even though 8.0 presumably
> includes much better high-level optimizers.

Version 8.0 can create faster code for some real world programs (at a price), 
this quote comes from the NAMD list:

[quote]
I just finished a compile of tcl, fftw, charm++ and namd all using the -xN
-O3 icc8.0  compiler flags.

Compared to the previous executable I get about a 13% gain in speed for
the same exact namd.config. I did notice that memory usage more than
doubled and this is troubling.
[/quote]

However, others are seeing some wierder problems, this quote is from the 
mpiexec list:

[quote]

But when run with ./a.out <inp all seems well.  The a.out exec was 
compiled with the mpif90 command.  I don't know who is at fault here, 
the compiler or mpiexec.  I have been told that old programs continue to 
work, even with the newly compiled mpiexec, but once recompiled with the 
v8 Intel compilers, all redirection breaks.

[/quote]

Pete W looked at the straces provided with and without mpiexec and saw:

[quote]

Note that the Intel compiler Fortran runtime library seems to be
statting stdin and finds a regular file in the "without" case, but
finds a socket in the "with" case.  Nevertheless it tries to seek
backwards one byte for both, which is not a valid thing to do on
a socket.
....
If you want to abstract mpiexec out of this to complain to intel,
try something like this:

    cat inp | rsh localhost strace -o $(pwd)/socket $(pwd)/a.out

I get S_IFSOCK and one-byte-at-a-time reads, but hopefully your
compiler will cause this to fail, just like in the mpiexec case.

[/quote]


-- 
 Christopher Samuel - (03)9925 4751 - VPAC Systems & Network Admin
 Victorian Partnership for Advanced Computing http://www.vpac.org/
 Bldg 91, 110 Victoria Street, Carlton South, VIC 3053, Australia

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL: <http://www.beowulf.org/pipermail/beowulf/attachments/20040716/14a170be/attachment.sig>