Linked by Thom Holwerda on Mon 16th Jun 2008 21:51 UTC, submitted by irbis
AMD AMD has seen a few serious setbacks lately, especially with their Barcelona server processor, but it seems as if the company is trying hard to get things back on track. The first step in solving an issue is acknowledging it exists in the first place, and AMD CEO Hector Ruiz did just that last December. "We blew it and we're very humbled by it and we learned from it and we're not going to do it again." Reseller Advocate Magazine asks, are you ready to believe him?
Thread beginning with comment 318716
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: dont underestimate AMD
by javiercero1 on Tue 17th Jun 2008 06:42 UTC in reply to "dont underestimate AMD"
javiercero1
Member since:
2005-11-10

Riiiiiiiight,

Here on planet earth, under similar conditions (same ISA, system, OS, configuration and optimization flags) there is no way a wider CPU, with better OOO scheduler, more aggressive branch predictor, larger caches, and which is running almost 25% faster clock cycle performs wors.

Unless AMD has some sort of pixie dust which breaks the rules of physics, or you are simply making stuff up.

I have both quad Opterons and Core2 Quads extensively, clock by clock the Core2 quad xeons take the Barcelona Opterons to the woodshed. Only in some very rare FPU codes the Opteron can use the memory controller to better stream data as opposed to the Quad Xeon. But if compare a 3Ghz Quad Xeon to a 2.2Ghz Quad Barcelona, I am yet to see a single piece of code I use that the Xeon is slower, the Barcelona for the most part is embarrassingly slower than the Xeon.

AMD is going to have to pull many hat tricks to overcome the fact that a) It does not have a fresh microarchitecture to compete with Nehalem (which is an almost completely new microarch from Intel), b) It can barely manage to produce 65nm parts, never mind that intel has had 45nm online for a while, with 3*nm nodes almost ready to go.

So indeed AMD will need all the pixie dust and denial to overcome the fact that they are at least their microarchitecture is 1 generation behind and unless they manage to pull it off and skip 45nm altogether, their fab may be 2 generations behind.

With the amount of money they are hemorrhaging, I have no clue where they are going to raise the hundreds of millions it takes to design a new microarchitecture and the billions it takes to get the new fab lines ready for sub 65nm nodes.

Reply Parent Score: 2

RE[2]: dont underestimate AMD
by bert64 on Tue 17th Jun 2008 09:29 in reply to "RE: dont underestimate AMD"
bert64 Member since:
2007-04-23

Riiiiiiiight,

Here on planet earth, under similar conditions (same ISA, system, OS, configuration and optimization flags) there is no way a wider CPU, with better OOO scheduler, more aggressive branch predictor, larger caches, and which is running almost 25% faster clock cycle performs wors.


It varies heavily depending on workload, different processors do different things better, for comparison i am using a Phenom 9600 (2.3ghz quad core), and a Q6600 (2.4ghz clocked to 2.3 for comparison purposes), both have 2GB DDR2/667 ram, tho the Q6600 is running in dual channel mode and the phenom is not (order f--ked up, it should have 4gb dual channel).
Both are running 64bit gentoo, compiled using gcc 4.3.1, cflags are =-O2 -fomit-frame-pointer -march=" with core2 or barcelona used as the -march appropriately.
All benchmarks are single threaded, and run with nice --19 so they can hog 1 core... Nothing else is running in the background aside from ssh (my login process).

John the ripper (single threaded) DES benchmark make linux-x86-64 using SSE2 asm:
Core2: Many salts: 2197K c/s real, 2201K c/s virtual
Phenom: Many salts: 1669K c/s real, 1669K c/s virtual

Compiling the same program using make generic (gcc optimizations, no sse2 asm) yields different results, using the default john CFLAGS:
Core2: Many salts: 1061K c/s real, 1061K c/s virtual
Phenom: Many salts: 1130K c/s real, 1130K c/s virtual

Running the synthetic flops benchmark (http://www.firenzee.com/flops.c) (compiled with -O3 -fomit-frame-pointer -march=core2/barcelona:

AMD:
Module Error RunTime MFLOPS
(usec)
1 4.0146e-13 0.0079 1769.8765
2 -1.4166e-13 0.0074 945.6464
3 4.7184e-14 0.0097 1751.3078
4 -1.2557e-13 0.0103 1457.3055
5 -1.3800e-13 0.0283 1025.4144
6 3.2380e-13 0.0176 1644.2968
7 -8.4583e-11 0.0254 471.5272
8 3.4867e-13 0.0274 1094.7969

INTEL:
Module Error RunTime MFLOPS
(usec)
1 4.0146e-13 0.0135 1038.9985
2 -1.4166e-13 0.0122 575.1838
3 4.7184e-14 0.0091 1868.4960
4 -1.2557e-13 0.0071 2118.3583
5 -1.3800e-13 0.0282 1026.7758
6 3.2380e-13 0.0138 2095.7179
7 -8.4583e-11 0.0407 294.7069
8 3.4867e-13 0.0283 1061.8881

So both processors are faster in some tests...

OpenSSL benchmarks are similar too, Intel seems to be faster at things like RC4, while AMD is faster at AES, tho the benchmarks are a bit too big to paste...

See:
http://www.firenzee.com/openssl-intel
http://www.firenzee.com/openssl-amd

I will re-run these tests when the dual channel memory for the AMD system turns up, but i doubt it will make much difference considering the nature of these benchmarks...

Ofcourse these benchmarks are a rough unscientific idea... Core2 may be faster at SSE2 code, or the asm written for john might simply be optimized for core2... Similarly with gcc, it could simply be that the architecture specific optimizations are better for phenom.

My experience has been that AMD systems generally seem quicker under load, and multi processor systems seem to outperform their Intel counterparts. The AMD system also seemed to compile the system packages faster than the Core2 system.

Of course, even if AMD cpus aren't up to scratch this time round, it was Intel's turn not so long ago with the P4 that was ridiculously inadequate. We need healthy competition between these two companies, or we'd be stuck with overheating single core P4 systems and proprietary RDRAM.

Reply Parent Score: 2

RE[3]: dont underestimate AMD
by mckill on Tue 17th Jun 2008 10:07 in reply to "RE[2]: dont underestimate AMD"
mckill Member since:
2007-06-12

those numbers are nice, but the Q6600 is ancient. i think the reality is AMD will be competing for the low-end while Intel will be able to release high-end products and provide under-clocked/semi faulty parts to beat up AMD's low-end market too.

Reply Parent Score: 1

RE[2]: dont underestimate AMD
by BluenoseJake on Tue 17th Jun 2008 11:21 in reply to "RE: dont underestimate AMD"
BluenoseJake Member since:
2005-08-11

"3Ghz Quad Xeon to a 2.2Ghz Quad Barcelona, I am yet to see a single piece of code I use that the Xeon is slower, the Barcelona for the most part is embarrassingly slower than the Xeon."

It's 800Mhz slower, what do you expect? An onboard memory controller can't make up for a 26% difference in speed. AMD's main problem is that they can't scale as well as Intel. If they could, they would be in a much better position.

Reply Parent Score: 4

RE[2]: dont underestimate AMD
by Redeeman on Tue 17th Jun 2008 12:01 in reply to "RE: dont underestimate AMD"
Redeeman Member since:
2006-03-23

Riiiiiiiight,

Here on planet earth, under similar conditions (same ISA, system, OS, configuration and optimization flags) there is no way a wider CPU, with better OOO scheduler, more aggressive branch predictor, larger caches, and which is running almost 25% faster clock cycle performs wors.

Unless AMD has some sort of pixie dust which breaks the rules of physics, or you are simply making stuff up.


I invite you to actually test yourself.

instead of your nice little pixie dust remarks, maybe you should.. i dont know... KNOW SOMETHING about what you are saying?

its really quite simple, for the code gcc generates for openssl, amd is superior, and as for gmp, the standard x86_64 implementation on AMD, beats the crap out of a special core2 asm hacky version, on core2.

Again, test it for yourself, then you will see.. And if you come here claim otherwise, then we will all simply know that you couldnt admit to being wrong..

Reply Parent Score: 4

javiercero1 Member since:
2005-11-10

You provide no quantitative numbers to back anything up, what is the system config, OS, compiler flags, etc, etc, etc.

The burden of the proof is on the one making the claims: i.e. you, not me.

I am yet to see a 3+Ghz core2 machine perform slower than a 2.4 Ghz Barcelona, period.

Reply Parent Score: 1

RE[3]: dont underestimate AMD
by Rugxulo on Thu 19th Jun 2008 21:03 in reply to "RE[2]: dont underestimate AMD"
Rugxulo Member since:
2007-10-09


its really quite simple, for the code gcc generates for openssl, amd is superior, and as for gmp, the standard x86_64 implementation on AMD, beats the crap out of a special core2 asm hacky version, on core2.


AMD is known for being very friendly to the GCC developers (et al.) and donating a lot of hardware. So, it's no surprise (and nice to hear) that GCC supports them well. Of course, the (in)famous Intel compiler is probably better for their chips, but they are supposedly? still kinda braindead re: SSE working on AMD chips (still using a "GenuineIntel" check ??).

Reply Parent Score: 1