AMD Talks About Internal Benchmarks for Opterons

ggruschow writes "AMD's CTO says their 2.0-Ghz Opteron (aka Hammer) beat a 2.8-Ghz Xeon (P4) on both SPECint2000 and SPECfp2000 tests, but was mixed against an Intel 1-Ghz Itanium 2 (details at ExtremeTech). IBM predicted "conservative" 1.8-Ghz PowerPC 970 scores, which fall in the middle of the pack (sweet for OS X). It's probably not a coincidence that AMD's news comes so soon after Gartner said x86-64 would fail. Even if Intel loses the performance crown again, their upcoming mobile processor is looking pretty spiff with its recently announced 1MB of cache. Sounds like next year might finally bring a worthy upgrade for my 486dx4-160."

Comments

Re:*sigh*

[tcdk]

For straight CPU intensive tasks it matters.

But for 99% of normal peoples taskes 10% whont matter.

But it's the edge and it has to be somewhere and it has to move.

My rule is that I upgrade when I can get a cpu that is twice as fast as my old one for about 1000dkr (130$/).

Thats possible right now (I've a 850Mh celeron), but I need a new motherboard, which kind of changes the rules.

Re:*sigh*

[tcdk]

How many people are "we"?

If you are ten people, one of them could be fired, by your argument, without anybody noticing.

Let me turn it around - how many procent do you need before it matters? 12? 15?

But I agree, one can't upgrade everytime theres a 10% speed increase. One has to do the cost/benefit thing carefully first (and then ignore the c/b and just spend, spend, spend - the only way to get the economy back on track ;)

Old hardware, old software and efficiency

[XNormal]

At work I've got a 49000 line Microsoft Visual C++ project that compiles in 5.5 minutes on a 1700 MHz Pentium 4. That's right, about 150 lines per second.

Turbo Pascal used to compile at thousands of lines per second on machines with a clock nearly two orders of magnitude slower that tool several cycles per instruction instead of running several instructions per cycle.

Before you say something like "hey, but moderns compilers have optimizations yadda yadda" perhaps I should mention that this compilation time was with no optimizations and features like updating browser files disabled. With optimization it's even slower.

We're talking about four orders of magnitude difference in efficiency here. It's not all the compiler's fault, of course. The libraries and code use complex templates and multiple levels of definitions that make the compiler work much harder.

At each one of these layers someone probably said "It's OK if this is 10 times slower. It's easier to write and maintain, I'm more productive (or lazy) and the CPU is fast enough". Each one of these decisions may be justified *in itself* but they add up (or rather multiply up) to a 1/10000 difference in efficiency. Slowing the edit/compile/debug cycle reduces programmer productivity and code quality. Reduced code quality to more code bloat and even slower edit/compile/debug cycle and so on.

Damn, it's depressing.

Re:Old hardware, old software and efficiency

[Junks Jerzey]

Turbo Pascal used to compile at thousands of lines per second on machines with a clock nearly two orders of magnitude slower that tool several cycles per instruction instead of running several instructions per cycle.

Object Pascal (Delphi) still compiles that fast, only now it does include optimization (maybe not as hardcore as some C compilers, but still pretty good). Borland used to advertise speeds of 800,000 lines per minute, back in the day when a 266MHz Pentium II was a hot machine. For most projects, the compilation speed is *zero*. For medium sized projects, it's in the "barely perceptible" range (as in maybe 1/30 second). Very, very impressive.

Why is it so fast? There are a variety of reasons, in rough order of importance:

1. There are no header files. All exported identifiers are in the "interface" section of the main source file.
2. Interface information is always precompiled into a lean format, so there's no need to #include giant files (kind of like having all headers always be precompiled).
3. There's no preprocessor.
4. "Object" files are stored in a lean "almost linked" intermediate format, rather than traditional, bulky object formats. This makes the linker a very simple and fast affair, but linking can be the slowest part of building a C++ project.
5. The compiler, linker, and build manager are all in one executable, so there's no loading programs during compilation (typically for C++, make is loaded first, the compiler is loaded for each source file, then the linker is loaded at the end; yes, disk caching helps here).
6. Object Pascal is generally a cleaner language than C and C++, so parsing and optimization are easier.

Re:How much is adequate?

[ottffssent]

No-one NEEDs more than a P100 tops

Yeah, but only in the way than no-one NEEDs modern medicine, central heating, or citrus fruit during the winter.

On the other hand, I NEED faster than a Duron/600 for:
sending messages in ICQ (yup, sending a message is O(n) or O(n^2) - not sure which) with n the number of messages in your scrollback
Encoding MP3s - I spent over 2 hours this afternoon switching CDs every 10-15 minutes.
Recording TV - I can only record to divx at quarter VGA or less
Using Mozilla the way I want (with 20-50 tabs open at a time and 128M of RAM cache)
Using an encrypted filesystem (unless win2k's implementation is just horribly inefficient)
Opening / manipulating 500M images

Sure, I could plop an XP2200+ in here, but I spent $50 on the original CPU and I'm unwilling to spend more on another until Hammer comes out. A dual Clawhammer should be about 10-20x as fast as my current machine depending on app - a most satisfying upgrade.