[Beowulf] Q: AMD Opteron (Barcelona) 2356 vs Intel Xeon 5460
kyron at neuralbs.com
Wed Sep 17 20:34:41 EDT 2008
Vincent Diepeveen wrote:
> I guess he's referring to sometimes it's using single precision
> floating point
> to get something done instead of double precision, and it tends to keep
> sometimes stuff in registers.
> That isn't a problem necessarily, but if i remember well floating
> point state
> could get wiped out when switching to SSE2.
> Sometimes you lose your FPU registerset in that case.
> Main problem is that there is so many dangerous optimizations possible,
> to speedup testsets, because in itself floating point is real slow to
> do at hardware,
> from hardware viewpoint seen.
> Yet in general last generations of intel compilers that has improved
> really a lot.
Well, running the same code here is the result discrepancy I got:
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 ;)
The running times (ran it a _few_ times...but not the statistical
minimum of 30):
ICC -> runtime == 689.249 ; summed error == 1651.78
GCC -> runtime == 1134.404 ; summed error == 0.883501
icc -xW -openmp -O3 vqOpenMP.c -o vqOpenMP
gcc -lm -fopenmp -O3 -march=native vqOpenMP.c -o vqOpenMP_GCC
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
... 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.
For the ones itching for a little more specs:
eric at einstein ~ $ icc -V
Intel(R) C Compiler for applications running on Intel(R) 64, Version
10.1 Build 20080602
Copyright (C) 1985-2008 Intel Corporation. All rights reserved.
FOR NON-COMMERCIAL USE ONLY
eric at einstein ~ $ gcc -v
Using built-in specs.
--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-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.3.1-r1
Thread model: posix
gcc version 4.3.1 (Gentoo 4.3.1-r1 p1.1)
> On Sep 17, 2008, at 10:25 PM, Greg Lindahl wrote:
>> On Wed, Sep 17, 2008 at 03:43:36PM -0400, Eric Thibodeau wrote:
>>> Also, note that I've had issues with icc
>>> generating really fast but inaccurate code (fp model is not IEEE *by
>>> default*, I am sure _everyone_ knows this and I am stating the obvious
>> All modern, high-performance compilers default that way. It's certainly
>> the case that sometimes it goes more horribly wrong than necessary, but
>> I wouldn't ding icc for this default. Compare results with IEEE mode.
>> -- greg
Beowulf mailing list, Beowulf at beowulf.org
To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
More information about the Beowulf