<div dir="ltr"><br><br>The scientific application used is Dl-Poly - 2.17.<br><br>Tested with Pathscale and Intel compilers on AMD Opteron Quad core. The time figures mentioned were taken from DL-Poly output file. Also I had used time command. Here are the results:<br>
<br><br> AMD-2.3GHz (32 GB RAM)
INTEL-2.33GHz (32 GB RAM)<br><br> GNU gfortran Pathscale Intel 10 ifort Intel 10 fiort<br>
<br>
1. Serial <br><br>OUTPUT file 147.719
sec 158.158 sec 135.729 sec 73.952 sec<br><div dir="ltr">
<br>Time command 2m27.791s 2m38.268s 1m13.972s<br><br>
2. Parallel <br> 4 core <br><br>OUTPUT file 39.798
sec 44.717 sec 36.962 sec 32.317 sec<br><br>Time Command 0m41.527s 0m46.571s 0m36.218s <br>
<br>
<br>3. Parallel <br> 8 core <br><br>OUTPUT 26.880
sec 33.746 sec 27.979 sec 30.371 sec<br><br>Time cmd 0m30.171s <br></div><br><br>The optimization flags used:<br>
<br>Intel ifort 10: -O3 -axW -funroll-loops (don't remember exact flag. Similar to loop unroll)<br><br>Pathscale: -O3 -OPT:Ofast -ffast-math -fno-math-errno<br><br>GNU gfortran -O3 -ffast-math -funroll-all-loops -ftree-vectorize<br>
<br><br>I'll try to use the further: <a href="http://directory.fsf.org/project/time/">http://directory.fsf.org/project/time/</a><br><br>Thanks,<br>Sangamesh<br><br><br><div class="gmail_quote">On Thu, Sep 18, 2008 at 6:07 AM, Vincent Diepeveen <span dir="ltr"><<a href="mailto:diep@xs4all.nl">diep@xs4all.nl</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">How does all this change when you use a PGO optimized executable on both sides?<br><font color="#888888">
<br>
Vincent</font><div><div></div><div class="Wj3C7c"><br>
<br>
On Sep 18, 2008, at 2:34 AM, Eric Thibodeau wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Vincent Diepeveen wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Nah,<br>
<br>
I guess he's referring to sometimes it's using single precision floating point<br>
to get something done instead of double precision, and it tends to keep<br>
sometimes stuff in registers.<br>
<br>
That isn't a problem necessarily, but if i remember well floating point state<br>
could get wiped out when switching to SSE2.<br>
<br>
Sometimes you lose your FPU registerset in that case.<br>
<br>
Main problem is that there is so many dangerous optimizations possible,<br>
to speedup testsets, because in itself floating point is real slow to do at hardware,<br>
from hardware viewpoint seen.<br>
<br>
Yet in general last generations of intel compilers that has improved really a lot.<br>
</blockquote>
Well, running the same code here is the result discrepancy I got:<br>
FLOPS:<br>
my code has to do: 7,975,847,125,000 (~8Tflops) ...takes 15minutes on 8*2core Opeteron with 32 Gigs-o-RAM (thank you OpenMP ;)<br>
<br>
The running times (ran it a _few_ times...but not the statistical minimum of 30):<br>
ICC -> runtime == 689.249 ; summed error == 1651.78<br>
GCC -> runtime == 1134.404 ; summed error == 0.883501<br>
<br>
Compiler Flags:<br>
icc -xW -openmp -O3 vqOpenMP.c -o vqOpenMP<br>
gcc -lm -fopenmp -O3 -march=native vqOpenMP.c -o vqOpenMP_GCC<br>
<br>
No trickery, no smoky mirrors ;) Just a _huge_ kick ASS k-Means parallelized with OpenMP (thank gawd, otherwise it takes hours to run) and a rather big database of 1.4 Gigs<br>
<br>
... So this is what I meant by floating point errors. Yes, the runtime was almost halved by ICC (and this is on an *opteron* based system, Tyan VX50). The running time wasn't what I was actually looking for rather than precision skew and that's where I fell off my chair.<br>
<br>
For the ones itching for a little more specs:<br>
<br>
eric@einstein ~ $ icc -V<br>
Intel(R) C Compiler for applications running on Intel(R) 64, Version 10.1 Build 20080602<br>
Copyright (C) 1985-2008 Intel Corporation. All rights reserved.<br>
FOR NON-COMMERCIAL USE ONLY<br>
<br>
eric@einstein ~ $ gcc -v<br>
Using built-in specs.<br>
Target: x86_64-pc-linux-gnu<br>
Configured with: /dev/shm/portage/sys-devel/gcc-4.3.1-r1/work/gcc-4.3.1/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.1 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.1 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.1/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.1/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.1/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --enable-multilib --enable-libmudflap --disable-libssp --enable-cld --disable-libgcj --enable-languages=c,c++,treelang,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=<a href="http://bugs.gentoo.org/" target="_blank">http://bugs.gentoo.org/</a> --with-pkgversion='Gentoo 4.3.1-r1 p1.1'<br>
Thread model: posix<br>
gcc version 4.3.1 (Gentoo 4.3.1-r1 p1.1)<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Vincent<br>
<br>
On Sep 17, 2008, at 10:25 PM, Greg Lindahl wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Wed, Sep 17, 2008 at 03:43:36PM -0400, Eric Thibodeau wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Also, note that I've had issues with icc<br>
generating really fast but inaccurate code (fp model is not IEEE *by<br>
default*, I am sure _everyone_ knows this and I am stating the obvious<br>
here).<br>
</blockquote>
<br>
All modern, high-performance compilers default that way. It's certainly<br>
the case that sometimes it goes more horribly wrong than necessary, but<br>
I wouldn't ding icc for this default. Compare results with IEEE mode.<br>
<br>
-- greg<br>
<br>
</blockquote></blockquote>
<br>
<br>
</blockquote>
<br>
_______________________________________________<br>
Beowulf mailing list, <a href="mailto:Beowulf@beowulf.org" target="_blank">Beowulf@beowulf.org</a><br>
To change your subscription (digest mode or unsubscribe) visit <a href="http://www.beowulf.org/mailman/listinfo/beowulf" target="_blank">http://www.beowulf.org/mailman/listinfo/beowulf</a><br>
</div></div></blockquote></div><br></div>