Slashdot Mirror

If you feel this is true, link to a single benchmark that doesn't use the intel compiler, and shows an AMD chip outperforming the i7-5960x. Otherwise, you are just blowing smoke.

https://www.spec.org/cgi-bin/o...

Feel free to point out any AMD processors that beat out the i7-5960X at 394.

https://www.cpubenchmark.net/
https://www.spec.org/cpu2006/r...

Are you sure about that? Everything I have read has stated that, while clock rates have plateaued, CPU performance increases pretty well every revision. Just because the new CPU has the same clock rate, doesn't mean that it is the same speed. I recently had to compare a HP Gen 7 server to Gen 8, only 2 years or so apart, same clock rates on the Xeons, but the newer one had literally twice the performance of the older system. Same number of cores, same clock rate, but the logic improvements doubled the performance for workloads.

This only mattered in our usage as these were for busy Exchange Hub servers, where they are CPU bound by the virus scan engine, so a double in performance is a double in the mail queue it can handle.

Looking at spec.org jEnterprise2010 scores:

http://spec.org/jEnterprise201...
http://spec.org/jEnterprise201...

A T5-2 gets a jEnterprise2010 score of 17k, an X4-2 11k (with half the memory and Oracle Broken Linux 5.9, why not 6.*?).

The sparc has a list price of ~68k USD. Not sure what a two socket Oracle intel box costs; maybe 15k or so?

sparc; 4 usd/score
intel: 1.36 usd/score

Sparc was nice once, but that was ever so long ago..

Looking at spec.org jEnterprise2010 scores:

http://spec.org/jEnterprise201...
http://spec.org/jEnterprise201...

A T5-2 gets a jEnterprise2010 score of 17k, an X4-2 11k (with half the memory and Oracle Broken Linux 5.9, why not 6.*?).

The sparc has a list price of ~68k USD. Not sure what a two socket Oracle intel box costs; maybe 15k or so?

sparc; 4 usd/score
intel: 1.36 usd/score

Sparc was nice once, but that was ever so long ago..

Impressive. You are wrong on just about *everything* you wrote:

>>POWER support is dead on all enterprise Linux distributions, Red Hat dropped support with EL5.
Nope and nope and nope

>>Furthermore OpenPower boxes are contractually prohibited from running AIX.
You are confusing this announcement with a previous attempt at the Linux market that was also called OpenPower. Those systems only ran Linux and could not run AIX. This announcement is about opening up the entire platform and licencing out parts or whole cores of the actual high end chips to companies like Google, who recognize that the single most expensive component in servers is the CPU - and they want choice and customization.

>>You've got a box of hardware with nothing to run on it and it can only deliver half the performance of comparatively priced Intel equipment.
The recently released Power7+ chip running Linux is the fastest thing on the market right now.

>> If you outsource support to IBM, their support specialists in the delivery centers will accidentally nuke your whole frame during routine maintenance, and you could be down for days
Umm..ok I'm stopping now

Impressive. You are wrong on just about *everything* you wrote:

>>POWER support is dead on all enterprise Linux distributions, Red Hat dropped support with EL5.
Nope and nope and nope

>>Furthermore OpenPower boxes are contractually prohibited from running AIX.
You are confusing this announcement with a previous attempt at the Linux market that was also called OpenPower. Those systems only ran Linux and could not run AIX. This announcement is about opening up the entire platform and licencing out parts or whole cores of the actual high end chips to companies like Google, who recognize that the single most expensive component in servers is the CPU - and they want choice and customization.

>>You've got a box of hardware with nothing to run on it and it can only deliver half the performance of comparatively priced Intel equipment.
The recently released Power7+ chip running Linux is the fastest thing on the market right now.

>> If you outsource support to IBM, their support specialists in the delivery centers will accidentally nuke your whole frame during routine maintenance, and you could be down for days
Umm..ok I'm stopping now

Sometimes the driver uses special optimized paths depending on the name of the executable. That was known in the past, so they could optimize for benchmarks and games. Even certain configurations of GL function calls were faster than others eg. glDrawArrays

http://www.spec.org/gwpg/gpc.static/Rulesv16.html

I'm curious, have you seen any of the SPEC_cpu benchmarks on SPARC64? You know, the ones that put a quad SPARC64 VII+ at performance roughly equivalent to a dual-core Phenom that's ~99% cheaper? How about the ones that show no marginal advantage of a SPARC T3 over a Magny-Cours Opteron, even when continiously saturated with threads, again with a vastly cheaper acquisition cost?

Didn't think so...

http://www.spec.org/cpu2006/results/res2011q2/

Why is this better than a 12-core Opteron with quad-channel DDR3?

Because each Intel core is a lot faster than each of the 12 cores on the latest Opterons. For many workloads, single-thread performance still matters. Search for "SPECint2006 Rate" results on the latest processors - a latest-gen Intel core is about twice as fast as an AMD Bulldozer core. 2*10 > 12

I try to buy the fastest single thread processor my budget allows. I go to

  http://www.spec.org/cgi-bin/osgresults?conf=cint2006&op=form

and run a query sorting in the "Key" "Primary" by "Baseline" Descending and then choose the fastes one I can buy. Easy and works for me.

I prefer Baseline because plenty of program are poorly compiled, without any optimization flag.

The only CPU measurement that matters is SPEC. That's an actual calculation of the most complex algorithms people have been able to devise and an explanation of how they work on each CPU. If you want to know which CPU is worth more, check its SPECint or SPECfp numbers.

http://www.spec.org/cpu2006/results/

For some odd reason you seem to rate integer and fpu as the measurement of performance.

Nate, dear boy, CPUs do integer and floating point computations. Would you care to inform us what other kinds of computations they do in order that we might measure them?

Is SPEC the ultimate measure? No, it's got plenty of known flaws, but it is a decent approximation as long as you take appropriate care when looking at submitted results (more on that below, as you fell for an intentionally misleading score).

As the rest of the world seems to know, there is more to speed than just benchmarks, unless you run benchmarks for a living. I speak of personal observations, "finding" things, rather than hard numbers because, frankly, there are lies, damned lies, and statistics. I compared my 200Mhz US II to my 1Ghz Pentium 3, and it responds faster, smoother, slicker. Both running Solaris 10, mind you.

The only reason you can imagine for a difference in subjective responsiveness is processor performance? Then you don't know anything.

If you insist on numbers, let's look at your SPEC2006 for the 2.66Ghz C2D E6700, 16.9 fp. Now let's compare that to a SPARC FPU, 28.8 by the SPARC 64 VII running at 2.5Ghz, slower than the C2D.

And here's where you fell for some 'creative' benchmarking. SPEC has always been the target of a lot of gaming by vendors, so you do have to take care.

Non-'rate' SPEC2006 is supposed to be a measure of a single CPU core, even in a multiprocessor system. This means that the scripts which run each benchmark in the SPEC suite only start one copy. (The 'rate' version starts N copies, where N is determined by the organiztion running the benchmark, and scores the throughput of the test as a whole.)

In recent years, autoparallelization compilation technology has been advancing. An autopar capable compiler can analyze the source code it's given and (sometimes) figure out ways to transform a single thread into multiple threads. If it does so, it inserts code to spawn threads and distribute work across however many processors are found at runtime.

Now, that's a useful thing, but if you allow autopar in a benchmark like SPEC2006, benchmarks may actually take advantage of multiple CPUs when the intent is to measure just one. Unfortunately, the SPEC2006 rules do allow autopar to be turned on, even in 'base' mode ('base' scores are supposed to have stricter rules for allowed optimizations than 'peak' scores). SPEC only requires that submitters must disclose the use of autopar.

This makes SPEC submissions with autopar enabled somewhat useless, because they don't measure what they're supposed to measure. Here's the source of your 28.8 CFP2006 score:

http://www.spec.org/cpu2006/results/res2008q3/cpu2006-20080711-04753.html

Look at the graphs of individual programs in the suite. Notice how 410.bwaves, 436.cactusADM, 459.GemsFDTD, and 470.lbm are all ridiculously high, and 434.zeusmp and 437.leslie3d are suspiciously high? Each score is the ratio of the execution times of that benchmark on the tested system and a reference system (a 296 MHz UltraSPARC II). It's simply not credible that a Sparc64 VII is 495x faster when running 410.bwaves but only ~11x to ~16x faster on most other benchmarks in the suite.

Scroll down further and you'll find the disclosure that they used autopar in the "Software" box. And in the Hardware section, you'll find that the machine tested has 64 CPU cores. Suddenly that 495x result makes a hell of a lot of sense. The multi-CPU scaling isn't perfect in every benchmark where autopar is able to do something, but autopar technology is not perfect, and for that matter few programs are capable of scaling linearly with the number of CPUs.

SPEC uses a geometric mean of the individual scores to calculate the final result, to reduce the impact of o

Funny thing is, I run an US II and find it's faster than a Pentium III of almost 5x the Mhz.

No you don't.

INT:
http://www.spec.org/osg/cpu2000/results/res2000q3/cpu2000-20000810-00176.html
http://www.spec.org/osg/cpu2000/results/res2000q4/cpu2000-20001129-00408.html

FP:
http://www.spec.org/osg/cpu2000/results/res2000q3/cpu2000-20000810-00177.html
http://www.spec.org/osg/cpu2000/results/res2000q4/cpu2000-20001121-00355.html

Summary of those numbers:
UltraSPARC II 480 MHz scores 234 SPECint2000, 291 SPECfp2000
Pentium III 1000 MHz scores 462 SPECint2000, 340 SPECfp2000

So, at a ratio of just over 2x clock rate, the P3 is ~2x faster at int and 1.16x faster at FP. Which makes your claim that an US II can beat a P3 clocked 5x faster completely absurd -- question SPEC's methodology all you want, you're completely out of touch if you are that far away from them.

(Of course, 'downix' is not anyone you'd want to consider an authority on anything, much less a legitimate challenge to SPEC's ability to design a proper benchmark. You're a pathological liar who has been faking expertise for years... 'Eddas' ring a bell?)

But you weren't done! You went on to stick your foot even further in your mouth:

You classify this as the platform, I spot it for what I and a lot of others recognize as a weakness of the US III. The III was Sun's P4, a high-priced pretty poor CPU.

A little more searching on the SPEC website reveals that (just to pick one example pair of scores) a SunBlade 150 with a 650 MHz US IIi scores 246/276 int/fp, and a SunBlade 1500 with a 1.062 GHz US IIIi scores 589/884.

And in another message you claimed:

I've found the SPARC FPU to perform better than the Core 2's, a lot more reliably if nothing else. In addition, the SPARC's threads complete in less cycles, enabling a slower per-thread CPU to keep up.

Bull. Complete bull.

Let's consider SPEC CPU2006 this time, only because the old CPU2000 benchmark probably hasn't ever been run on a Core 2.

It so happens that CPU2006 is normalized to an UltraSPARC 2 running at 296 MHz (the Ultra Enterprise 2). In other words, that processor by definition scores 1.0 on both the integer and FP tests.

The 2.66 GHz Core 2 Duo E6700 scores 20.0 int, 16.9 fp.

Even if you have the fastest US II ever made (the 650 MHz US IIe+), there is simply no way your US II's FP performance could even *touch* a Core 2's. You're in the realm of completely ludicrous claims, here.

You can't even save yourself with a weak back-off to per-cycle efficiency: notice how the C2's clock is less than 10x as much as the US II, yet its performance is much more than 10x higher?

Nate, why do you so often feel the urge to lie about things like this?

Funny thing is, I run an US II and find it's faster than a Pentium III of almost 5x the Mhz.

No you don't.

INT:
http://www.spec.org/osg/cpu2000/results/res2000q3/cpu2000-20000810-00176.html
http://www.spec.org/osg/cpu2000/results/res2000q4/cpu2000-20001129-00408.html

FP:
http://www.spec.org/osg/cpu2000/results/res2000q3/cpu2000-20000810-00177.html
http://www.spec.org/osg/cpu2000/results/res2000q4/cpu2000-20001121-00355.html

Summary of those numbers:
UltraSPARC II 480 MHz scores 234 SPECint2000, 291 SPECfp2000
Pentium III 1000 MHz scores 462 SPECint2000, 340 SPECfp2000

So, at a ratio of just over 2x clock rate, the P3 is ~2x faster at int and 1.16x faster at FP. Which makes your claim that an US II can beat a P3 clocked 5x faster completely absurd -- question SPEC's methodology all you want, you're completely out of touch if you are that far away from them.

(Of course, 'downix' is not anyone you'd want to consider an authority on anything, much less a legitimate challenge to SPEC's ability to design a proper benchmark. You're a pathological liar who has been faking expertise for years... 'Eddas' ring a bell?)

But you weren't done! You went on to stick your foot even further in your mouth:

You classify this as the platform, I spot it for what I and a lot of others recognize as a weakness of the US III. The III was Sun's P4, a high-priced pretty poor CPU.

A little more searching on the SPEC website reveals that (just to pick one example pair of scores) a SunBlade 150 with a 650 MHz US IIi scores 246/276 int/fp, and a SunBlade 1500 with a 1.062 GHz US IIIi scores 589/884.

And in another message you claimed:

I've found the SPARC FPU to perform better than the Core 2's, a lot more reliably if nothing else. In addition, the SPARC's threads complete in less cycles, enabling a slower per-thread CPU to keep up.

Bull. Complete bull.

Let's consider SPEC CPU2006 this time, only because the old CPU2000 benchmark probably hasn't ever been run on a Core 2.

It so happens that CPU2006 is normalized to an UltraSPARC 2 running at 296 MHz (the Ultra Enterprise 2). In other words, that processor by definition scores 1.0 on both the integer and FP tests.

The 2.66 GHz Core 2 Duo E6700 scores 20.0 int, 16.9 fp.

Even if you have the fastest US II ever made (the 650 MHz US IIe+), there is simply no way your US II's FP performance could even *touch* a Core 2's. You're in the realm of completely ludicrous claims, here.

You can't even save yourself with a weak back-off to per-cycle efficiency: notice how the C2's clock is less than 10x as much as the US II, yet its performance is much more than 10x higher?

Nate, why do you so often feel the urge to lie about things like this?

Funny thing is, I run an US II and find it's faster than a Pentium III of almost 5x the Mhz.

No you don't.

INT:
http://www.spec.org/osg/cpu2000/results/res2000q3/cpu2000-20000810-00176.html
http://www.spec.org/osg/cpu2000/results/res2000q4/cpu2000-20001129-00408.html

FP:
http://www.spec.org/osg/cpu2000/results/res2000q3/cpu2000-20000810-00177.html
http://www.spec.org/osg/cpu2000/results/res2000q4/cpu2000-20001121-00355.html

Summary of those numbers:
UltraSPARC II 480 MHz scores 234 SPECint2000, 291 SPECfp2000
Pentium III 1000 MHz scores 462 SPECint2000, 340 SPECfp2000

So, at a ratio of just over 2x clock rate, the P3 is ~2x faster at int and 1.16x faster at FP. Which makes your claim that an US II can beat a P3 clocked 5x faster completely absurd -- question SPEC's methodology all you want, you're completely out of touch if you are that far away from them.

(Of course, 'downix' is not anyone you'd want to consider an authority on anything, much less a legitimate challenge to SPEC's ability to design a proper benchmark. You're a pathological liar who has been faking expertise for years... 'Eddas' ring a bell?)

But you weren't done! You went on to stick your foot even further in your mouth:

You classify this as the platform, I spot it for what I and a lot of others recognize as a weakness of the US III. The III was Sun's P4, a high-priced pretty poor CPU.

A little more searching on the SPEC website reveals that (just to pick one example pair of scores) a SunBlade 150 with a 650 MHz US IIi scores 246/276 int/fp, and a SunBlade 1500 with a 1.062 GHz US IIIi scores 589/884.

And in another message you claimed:

I've found the SPARC FPU to perform better than the Core 2's, a lot more reliably if nothing else. In addition, the SPARC's threads complete in less cycles, enabling a slower per-thread CPU to keep up.

Bull. Complete bull.

Let's consider SPEC CPU2006 this time, only because the old CPU2000 benchmark probably hasn't ever been run on a Core 2.

It so happens that CPU2006 is normalized to an UltraSPARC 2 running at 296 MHz (the Ultra Enterprise 2). In other words, that processor by definition scores 1.0 on both the integer and FP tests.

The 2.66 GHz Core 2 Duo E6700 scores 20.0 int, 16.9 fp.

Even if you have the fastest US II ever made (the 650 MHz US IIe+), there is simply no way your US II's FP performance could even *touch* a Core 2's. You're in the realm of completely ludicrous claims, here.

You can't even save yourself with a weak back-off to per-cycle efficiency: notice how the C2's clock is less than 10x as much as the US II, yet its performance is much more than 10x higher?

Nate, why do you so often feel the urge to lie about things like this?

Funny thing is, I run an US II and find it's faster than a Pentium III of almost 5x the Mhz.

No you don't.

INT:
http://www.spec.org/osg/cpu2000/results/res2000q3/cpu2000-20000810-00176.html
http://www.spec.org/osg/cpu2000/results/res2000q4/cpu2000-20001129-00408.html

FP:
http://www.spec.org/osg/cpu2000/results/res2000q3/cpu2000-20000810-00177.html
http://www.spec.org/osg/cpu2000/results/res2000q4/cpu2000-20001121-00355.html

Summary of those numbers:
UltraSPARC II 480 MHz scores 234 SPECint2000, 291 SPECfp2000
Pentium III 1000 MHz scores 462 SPECint2000, 340 SPECfp2000

So, at a ratio of just over 2x clock rate, the P3 is ~2x faster at int and 1.16x faster at FP. Which makes your claim that an US II can beat a P3 clocked 5x faster completely absurd -- question SPEC's methodology all you want, you're completely out of touch if you are that far away from them.

(Of course, 'downix' is not anyone you'd want to consider an authority on anything, much less a legitimate challenge to SPEC's ability to design a proper benchmark. You're a pathological liar who has been faking expertise for years... 'Eddas' ring a bell?)

But you weren't done! You went on to stick your foot even further in your mouth:

You classify this as the platform, I spot it for what I and a lot of others recognize as a weakness of the US III. The III was Sun's P4, a high-priced pretty poor CPU.

A little more searching on the SPEC website reveals that (just to pick one example pair of scores) a SunBlade 150 with a 650 MHz US IIi scores 246/276 int/fp, and a SunBlade 1500 with a 1.062 GHz US IIIi scores 589/884.

And in another message you claimed:

I've found the SPARC FPU to perform better than the Core 2's, a lot more reliably if nothing else. In addition, the SPARC's threads complete in less cycles, enabling a slower per-thread CPU to keep up.

Bull. Complete bull.

Let's consider SPEC CPU2006 this time, only because the old CPU2000 benchmark probably hasn't ever been run on a Core 2.

It so happens that CPU2006 is normalized to an UltraSPARC 2 running at 296 MHz (the Ultra Enterprise 2). In other words, that processor by definition scores 1.0 on both the integer and FP tests.

The 2.66 GHz Core 2 Duo E6700 scores 20.0 int, 16.9 fp.

Even if you have the fastest US II ever made (the 650 MHz US IIe+), there is simply no way your US II's FP performance could even *touch* a Core 2's. You're in the realm of completely ludicrous claims, here.

You can't even save yourself with a weak back-off to per-cycle efficiency: notice how the C2's clock is less than 10x as much as the US II, yet its performance is much more than 10x higher?

Nate, why do you so often feel the urge to lie about things like this?

http://www.spec.org/cpu2006/Docs/readme1st.html#Q15

There are several different ways to measure computer performance. One way is to measure how fast the computer completes a single task; this is a speed measure. Another way is to measure how many tasks a computer can accomplish in a certain amount of time; this is called a throughput, capacity or rate measure.
The SPEC speed metrics (e.g., SPECint2006) are used for comparing the ability of a computer to complete single tasks.
The SPEC rate metrics (e.g., SPECint_rate2006) measure the throughput or rate of a machine carrying out a number of tasks.

For the rate metrics, multiple copies of the benchmarks are run simultaneously. Typically, the number of copies is the same as the number of CPUs on the machine, but this is not a requirement. For example, it would be perfectly acceptable to run 63 copies of the benchmarks on a 64-CPU machine (thereby leaving one CPU free to handle system overhead).

SpecInt2006 and SpecFP2006 are both single core benchmarks, it is only SpecRate which is multicore. In which case this shows a 3Ghz Nehalem has more performance per core than a 5Ghz PPC. That's not too unexpected actually, Nehalem is out of order and POWER6 isn't.

Looking at int rate for 4 cores, which really is a multicore benchmark,

http://www.onscale.de/specbrowser/2006-ir-004.html

it seems like Nehalem is still ahead, but not by as much. Same with int rate for 8 CPUs

http://www.onscale.de/specbrowser/2006-ir-008.html

Now for FP rate the picture is different

http://www.onscale.de/specbrowser/2006-fr-004.html

Power6 does indeed come out ahead. And for the rate scores with more than 16 cores, pretty much all the scores are for Risc because no one bothers to make x86 machines with that many cores. Mind you Larrabee might change that. Larrabee is in order too, has loads of cores and a wide vector FP unit. If all the rhetoric about being vector complete is true, it seems like it would score very well on Spec FP rate for lots of cores, something x86 is still weak at.

Well if you really want to play that game here's the power6 64-core benchmark.
http://www.spec.org/cpu2006/results/res2008q2/cpu2006-20080407-04058.html

1820 SpecInt marks. Well over 20 times the score of the x5570 in every category.

Of course the number of cores can be whatever the box maker wants it to be. So it's a stupid comparison. The only fair comparison is a per-core comparison.

Look i hate to be anal, but neither Intel nor AMD have been at the top of the SpecInt benchmark for a long time.
The stock IBM Power6 5.0Ghz CPU is the fastest CPU on the specint benchmark on a per-core basis (and before that it was the 4.7Ghz model of the same CPU that was the leader).

http://www.spec.org/cpu2006/results/res2008q2/cpu2006-20080407-04057.html
Search for: IBM Power 595 (5.0 GHz, 1 core)
Which is telling considering it's made on a larger process than the fastest x86 (the i7). It really shows there's room for improvement if you ditch the x86 instruction set.

One of the main things that would make Nehalem attractive is a few things for blade servers. The process 45nm moving on to 32nm later will provide the smallest footprint while not giving up any CPU power. Also, the Nehalems (Bloomfield and Core i7) that I have tested don't seem to offer much in terms of better performance, but the power usage is considerably lower. Also, FB-DIMMS (and DDR2) were a bit too consumptive of power, the newer memory technology is an attempt to reduce power consumption. Also, the CPI (formerly CSI) offers the Intel CPUs a Hypertransport-like interconnect system allowing system builders to scale. The footprint of 16+ core systems with Nehalem will be far smaller than the previous generations of Xeon MP processors.

I think the idea is more memory, more CPU processing power, less power and heat and scalability with a given architecture.

I noticed in my testing the L1 Data and instruction caches (32KB per core) in the Core i7 is one cycle more latent than the core2 (4 cycles vs 3), the L2 cache (which is 256KB per core rather than the 4-6MB per two cores in Core2) is faster, down from 17 cycles to 12 cycles. With this boost in L2-speed came a cut of 3.75MB-5.75MB in size. The way they mitigated that loss was to give a "large" 8MB L3 cache that runs on a slower clock. This new system, along with a hyper-threading implementation that, unlike the previous one, seems to genuinely enhance performance in nearly every test, allows Intel to make top-performing chips (see CPU 2006 @ spec.org for the latest results) that scale better via QPI, use less power and fit into smaller spaces than previous chips.

See:
Sorted SPEC CPU2006 Integer and Floating Point

CINT2006
Hardware Vendor System Result Baseline # Cores # Chips # Cores Per Chip Published Disclosure
1) YOYOtech Fi7EPOWER MLK1610 (Intel Core i7-965) 36.0 32.5 4 1 4 Jan-2009
2) ASUSTeK Computer Inc. ASUS P6T WS PRO workstation motherboard (Intel Core i7-965 Extreme Edition) 35.2 31.5 4 1 4
3) ASUSTeK Computer Inc. Asus P6T Deluxe (Intel Core i7-965 Extreme Edition) 33.6 30.2 4 1 4 Nov-2008
4) ASUSTeK Computer Inc. Asus P6T Deluxe (Intel Core i7-940) 30.8 27.8 4 1 4
5) Dell Inc. Dell Precision T7400 (Intel Xeon X5492, 3.40 GHz) 30.2 27.6 8 2 4

CFP2006
Hardware Vendor System Result Baseline # Cores # Chips # Cores Per Chip Published Disclosure
1) ASUSTeK Computer Inc. ASUS P6T WS PRO workstation motherboard (Intel Core i7-965 Extreme Edition) 39.3 37.4 4 1 4 Feb-2009
2) YOYOtech Fi7EPOWER MLK1610 (Intel Core i7-965) 35.7 33.6 4 1 4 Jan-2009
3)ASUSTeK Computer Inc. Asus P6T Deluxe (Intel Core i7-965 Extreme Edition) 33.6

OK. Seems my assumption that the CFP2006 benchmarks are single threaded was wrong (it can be multithreaded and use multiple cores if "auto parallel"=yes).

Even so, the POWER6 still doesn't seem that much faster - certainly not 100% faster.

Back in 2007, the 2400MHz Intel Xeon 3060 still got a score of about 15 with only 1 core enabled. The 4.7GHz POWER6 score of 18.7 is not 50% or 100% more/faster than 15.

See:
http://www.spec.org/cpu2006/results/res2007q2/cpu2006-20070329-00693.html
http://www.spec.org/cpu2006/results/res2007q2/cpu2006-20070611-01218.html

You have to understand it's a bit hard to do apples to apples comparisons because:

1) Though IBM did post a 5GHz POWER6 score of 20.1 last year (2008), I don't see "cores=1" submissions for Intel chips last year.
2) There are no cores > 1 scores for POWER6.

As it is, I'm inclined to think that the x86 has caught up with the POWER6's CFP2006 performance, if not surpassed it already.

My reasoning is the POWER6 has not got much faster since 2007 (4.7GHz -> 5GHz, with no change in architecture).

Whereas the 3733MHz Intel Core i7-965 Extreme Edition is definitely a lot faster than the 2400MHz Intel Xeon 3060 - (which got a score of 15 with one core).

The i7 is a new architecture with maybe 10-15% faster per clock, and 3733MHz is a fair bit faster than 2400MHz (BTW the performance/watt is very competitive too).

So it's near certain that a 3.733GHz i7 would beat a 5GHz POWER6 in single core performance in both CFP2006 and CINT2006.

It's impressive how fast the x86 can go :p.

I don't think it's going to be easy for the POWER/SPARC/Itanium teams to beat the x86 in performance, or even performance/watt (for high performance computing).

OK. Seems my assumption that the CFP2006 benchmarks are single threaded was wrong (it can be multithreaded and use multiple cores if "auto parallel"=yes).

Even so, the POWER6 still doesn't seem that much faster - certainly not 100% faster.

Back in 2007, the 2400MHz Intel Xeon 3060 still got a score of about 15 with only 1 core enabled. The 4.7GHz POWER6 score of 18.7 is not 50% or 100% more/faster than 15.

See:
http://www.spec.org/cpu2006/results/res2007q2/cpu2006-20070329-00693.html
http://www.spec.org/cpu2006/results/res2007q2/cpu2006-20070611-01218.html

You have to understand it's a bit hard to do apples to apples comparisons because:

1) Though IBM did post a 5GHz POWER6 score of 20.1 last year (2008), I don't see "cores=1" submissions for Intel chips last year.
2) There are no cores > 1 scores for POWER6.

As it is, I'm inclined to think that the x86 has caught up with the POWER6's CFP2006 performance, if not surpassed it already.

My reasoning is the POWER6 has not got much faster since 2007 (4.7GHz -> 5GHz, with no change in architecture).

Whereas the 3733MHz Intel Core i7-965 Extreme Edition is definitely a lot faster than the 2400MHz Intel Xeon 3060 - (which got a score of 15 with one core).

The i7 is a new architecture with maybe 10-15% faster per clock, and 3733MHz is a fair bit faster than 2400MHz (BTW the performance/watt is very competitive too).

So it's near certain that a 3.733GHz i7 would beat a 5GHz POWER6 in single core performance in both CFP2006 and CINT2006.

It's impressive how fast the x86 can go :p.

I don't think it's going to be easy for the POWER/SPARC/Itanium teams to beat the x86 in performance, or even performance/watt (for high performance computing).

Go to: http://www.spec.org/cgi-bin/osgresults?conf=cpu2006;op=form

Change Processor from SKIP to Display.

Order by published asc, baseline desc, result desc.

Submit the form.

Look for the CFP2006 benchmarks.

Then look from then on.

You will see that the POWER6 or Itanium 2 lead over the x86 at any time was rather low.

In Aug 2007, the Intel Core 2 Duo E6850 was about even with the POWER6.
By Oct 2007 the x86 Intel Xeon X7350 was leading.

AFAIK the CFP2006 benchmarks are single threaded performance tests, and the "CFP2006 Rates" are for multithreaded tests.

The x86 may be an ugly pig, but it now has a huge jetpack strapped on.
So the "elegant" eagles that want to be as fast now also have to wear huge and ugly jetpacks.

From a distance they now look about the same and run about as hot :).

Go here: http://www.spec.org/cgi-bin/osgresults?conf=cpu2006;op=form

Select to display the processor name. Sort primary by results. Scroll to the bottom. In a 4-way configuration the Xeon X7350 DOES NOT EVEN COME CLOSE to the Opteron WITH THE TLB BUG at 2.3GHz. That's with the erratum. Not that it's competing now, but with the TLB-bug-free and higher-clocked revs coming soon the Xeon will not compete in this space. Currently AMD's architecture is superior to Intel's on 4-way and up. The money is not made on fanboi gamer rigs. Thanks for playing. By the end of 2008 AMD should have the advantage across the board.

The results in terms of a car are miles/kilometres travelled. In terms of computers, MIPS or MFLOPS are however not results, they are performance measurements. Using them would be like describing car efficiency in RPM per gallon. Not the results you're after.

So the first thing to do is define what your results are. The results computers produce are the "bits of information you want".

SPEC and TPC both have benchmarks which already attempt to describe the results that customers are after.

http://www.spec.org/
http://www.tpc.org/

Yes it's great that EPA is working with industry to get some more meaningful power ratings of computer equipment. But it's not easy to give "typical" energy use. What's typical gas mileage of your car? Does a 25 MPG EPA rating mean you'll get 25 MPG? How heavy is your foot, where do you drive, how far, how hilly, how many stoplights, etc.?

From the SPEC power benchmark you'll get not just a single composite number, but all the details so you can judge what is most relevant to your own system. Is it idle most of the day? Then look at that end of the graph, and check the power management software settings to automatically suspend. Does it run flat out? Then look at that end of the graph. For even better information you can test your own systems with your own workload.

The forthcoming energy efficiency benchmark from SPEC is generally described at http://www.spec.org/specpower/

The 2.0GHz Barcelona beats the 3.0GHz Xeon X5365 (Cloverton) on floating point. Barcelona specfp_rate2006 score is 73.0 to Cloverton's 66.9. Things can only get better as AMD cranks up the clock in the coming months.

If you scale the benchmarks to the same GHz rating you will see that clock for clock Barcelona is at worst on par with Intel's best chip, and at best 80% faster on floating point. This is really quite amazing when you consider it's using the same amount of power as the previous 2 core AMD Opteron.

I don't believe I've heard of a NetApp 2050. I've heard of their 200 series, 800, 900, 3000 and 6000, but not 2000.

In looking at the following link to speed, it appears that Sun's ops/sec rating is a little bit behind the NetApp units. And they don't mention the Sun 6140, so I don't know if it hasn't been tested yet or it is a typo.

Your experience isn't shread by me, or by most other benchmarkers. Take a look at multi-threaded SPEC benchmarks for the Xeon 5300 series. SPEC_int_rate 2006, SPEC JBB_2005, etc, all show the Xeon 5300 as the clear per-socket performance leader for x86 systems. The quad-core Xeons are only bested by the IBM POWER 6, and Niagra in the Java benchmarks.

See the SPECint_rate 2006 results page, and filter on two-chip systems.

Perhaps your particular application is a degenerate case for the 5300s cache architecture, but I have to tell you our Xeon X5355 based Dells are (by almost a factor of two) the fastest dual-socket application servers we have, much faster than the dual-core Opteron systems we have that run the same apps and are just a few months older.

AMD is still way ahead of Intel when it comes to jobs which combine these two things:

• floating point (general purpose, not just video-encoding primitives)
• use of lots of RAM in "non-cache-friendly" ways

Barcelona is supposed to increase scalability even a bit more from the current Opterons. Let's see if Intel comes up with something in this department. So far they have not, and that's why most scientific computing in the last 5 years is done on Opterons.

http://spec.org/ Without knowing your workload type, which benchmark are you hoping for? As a generic benchmark I've used SPEC INT RATE 2000 and TPM - both are flawed since almost no real work looks like them.

Try following the HTML link - http://www.spec.org/jAppServer2004/results/res2007 q3/jAppServer2004-20070606-00065.html

Is more indepth on the systems and tuning parameters used.

PostgreSQL setup: 8 cores, 16GB RAM.

Oracle setup: 64 cores, 512GB RAM.

PostgreSQL setup: 8 cores, 16GB RAM.

Oracle setup: 64 cores, 512GB RAM.

PostgresSQL: 778.14
Oracle 10gR2: 6,812.79

Real close, I agree.. Postgres had a 40GB cache, Oracle used 21GB
See http://www.spec.org/osg/jAppServer2004/results/res 2006q4/jAppServer2004-20061121-00046.html

From the link in the article you can find the results, or just look here.

Hardware, kernel changes, PostgreSQL configuration, etc.
Its all on that page.

This publication shows that a properly tuned PostgreSQL is not only as fast or faster than MySQL, but almost as fast as Oracle (since the hardware platforms are different, it's hard to compare directly). This is something we've been saying for the last 2 years, and now we can prove it.

The UltraSPARC has 8 cores on 1 chip and 16GB of memory.
The Opteron has 4 cores and 8GB of memory.

The UltraSPARC should smoke it every time.

This publication shows that a properly tuned PostgreSQL is not only as fast or faster than MySQL, but almost as fast as Oracle (since the hardware platforms are different, it's hard to compare directly). This is something we've been saying for the last 2 years, and now we can prove it.

The UltraSPARC has 8 cores on 1 chip and 16GB of memory.
The Opteron has 4 cores and 8GB of memory.

The UltraSPARC should smoke it every time.

http://www.spec.org/jAppServer2004/results/jAppSer ver2004.html contains all the results. Unfortunately the different hardware configurations make it rather hard to draw any conclusions. Which begs the question, how did the submiter knew that these specific guys where biased or not? From what I can see, the whole setup is inherently biased.

I think that somebody sent the wrong link and (surprise!) the editors didn't even follow it to check.

Here's a more useful one: All SPEC jAppServer2004 Results Published by SPEC

The benchmarks aren't standardized enough for any useful comparison. The hardware and configurations vary in almost every one.

Why this emaciated post made it while mine didn't I'll never know...here's how I submitted this story:
 
The current version of PostgreSQL now has its first real benchmark, a SPECjAppServer2004 submission from Sun Microsystems. The results required substantial tuning of many performance-related PostgreSQL parameters, some of which are set to extremely low values in the default configuration — a known issue that contributes to why many untuned PostgreSQL installations appear sluggish compared to its rivals. The speed result is close but slightly faster than an earlier Sun submission using MySQL 5 (with enough hardware differences to make a direct comparison of those results unfair), and comes close to keeping up with Oracle on similarly priced hardware — but with a large software savings. Having a published result on the level playing field of an industry-standard benchmark like SPECjAppServer2004, with documentation on all the tuning required to reach that performance level, should make PostgreSQL an easier sell to corporate customers who are wary of adopting open-source applications for their critical databases.

Why this emaciated post made it while mine didn't I'll never know...here's how I submitted this story:
 
The current version of PostgreSQL now has its first real benchmark, a SPECjAppServer2004 submission from Sun Microsystems. The results required substantial tuning of many performance-related PostgreSQL parameters, some of which are set to extremely low values in the default configuration — a known issue that contributes to why many untuned PostgreSQL installations appear sluggish compared to its rivals. The speed result is close but slightly faster than an earlier Sun submission using MySQL 5 (with enough hardware differences to make a direct comparison of those results unfair), and comes close to keeping up with Oracle on similarly priced hardware — but with a large software savings. Having a published result on the level playing field of an industry-standard benchmark like SPECjAppServer2004, with documentation on all the tuning required to reach that performance level, should make PostgreSQL an easier sell to corporate customers who are wary of adopting open-source applications for their critical databases.

Why this emaciated post made it while mine didn't I'll never know...here's how I submitted this story:
 
The current version of PostgreSQL now has its first real benchmark, a SPECjAppServer2004 submission from Sun Microsystems. The results required substantial tuning of many performance-related PostgreSQL parameters, some of which are set to extremely low values in the default configuration — a known issue that contributes to why many untuned PostgreSQL installations appear sluggish compared to its rivals. The speed result is close but slightly faster than an earlier Sun submission using MySQL 5 (with enough hardware differences to make a direct comparison of those results unfair), and comes close to keeping up with Oracle on similarly priced hardware — but with a large software savings. Having a published result on the level playing field of an industry-standard benchmark like SPECjAppServer2004, with documentation on all the tuning required to reach that performance level, should make PostgreSQL an easier sell to corporate customers who are wary of adopting open-source applications for their critical databases.

1. Feature Set:
   First off, every serious NAS/SAN vendor is going to have a snapshot solution. Here are a couple other features you might need: Automatic Replication, High-Availablity / Failover, Integrated Virus Scanning, Clustering. Many of the "exciting" features listed in Sun's press releases are not even vaguely revolutionary.
2. Manageability:
   As the name "NetApp" may imply, NAS/SAN vendors often sell "appliances" that attempt to simplify many of the management concerns (e.g. monitoring, automation of backups, etc). How well they do this varies from vendor to vendor and based on what features you need.
3. Compatibility:
   Large NAS/SAN vendors have already verified that their product works with a number of 3rd-party apps and hardware. Will your old tape hardware work well with ZFS? Is SQL certified to run on ZFS? Will Sun's customer support help you if you do get things working? Likely not.
4. Performance:
   For all the business I've heard about ZFS being the "last word in file systems", the amount of actual performance data has been incredibly lacking. For example, most NFS products have published their SPEC numbers. Although these performance results are often gamed a bit, they're the current standard for NFS performance.
   The performance numbers I have seen with ZFS so far are useless (e.g. see here for someone measuring how fast ZFS can write to RAM or here for someone getting the blazing throuput of 45 mb/s). Filesystem-based iSCSI solutions (as opposed to SANs) tend to have terrible performance (this includes some of NetApp's products), so I'm a bit dubious about claims that ZFS does iSCSI faster than it does NFS.
5. Reliability:
   In addition to reliability features such as High-Availability and Disaster Recovery, how many enterprise production environments is ZFS actually running in? How many data corruption bugs are waiting to be ironed out? How mature are the repair tools (e.g. fsck)?
   Also, enterprise NAS/SANs (e.g. those of NetApp) often have a nice feature where an operation is stable once the client receives an ACK. They get this by logging pending operations to non-volatile RAM. As far as I can tell this is not possible with ZFS, which means that your applications need to be aware that operations may need to be resent to the server after crash.

Disclaimer: I AM a Storage Engineer at one of the big 3 SAN/NAS houses.

Here's what you get:
Double Parity RAID instead of RAID-5. Thousands of times more resillient. Read the latest literature on disk failure rates on SATA drives and then try to sleep at night knowing you only have RAID-5.

Speed: Dedicated storage OSes are optimized for raw speed. For more info see: Standard Performance Evaluation Corporation

Expandability: How much downtime do you require to expand your homebrewed system? Most commercial storage systems require none.

Support: What happens WHEN you do have a multi-disk failure (notice I said WHEN and not IF)? We can recover most multi-disk failures without data loss. Can you do that?

Disaster recovery and business continuity: Big box storage systems are built around this. What are you going to tell your CIO/Insurance company?

Sure, we cost more.
But how much is your data worth?

SPECint* do scale almost perfectly. Not SPECint* 2006 anyway.
Results here: SPECint and SPECint_rate.

Take a look at the Itanium results. Yeah, it's itanic. But HP's the only to actually post results for various frequencies and cache size on the same box.
And that makes it quite obvious that neither bench scales "perfectly" with clockspeed.

If process technology had met Intel's marketing projections, we'd still be stuck with 6GHz monsters idling on pipeline stalls and cache misses.

SPECint* do scale almost perfectly. Not SPECint* 2006 anyway.
Results here: SPECint and SPECint_rate.

Take a look at the Itanium results. Yeah, it's itanic. But HP's the only to actually post results for various frequencies and cache size on the same box.
And that makes it quite obvious that neither bench scales "perfectly" with clockspeed.

If process technology had met Intel's marketing projections, we'd still be stuck with 6GHz monsters idling on pipeline stalls and cache misses.

The IBM Power 5

http://www.spec.org/cpu2000/results/