Conroe benchmarking results under Unix

[uOpt]

A person offered me to run my Unix benchmark suite on a Conroe E6600 R5.

First run is non-overclocked (update, now also at 3.0 GHz):
- Conroe E6600
- 2x 1 GB non-ECC DDR2
- Bad Axe 3.04 unmodded

I'm posting as the suite runs through. It is not complete yet but I don't expect that to happen before I hit the sack.

Single-thread/process benchmarks 32 bit, user CPU time (wall clock multithreaded comes later). Not complete yet, but has scripting, Lisp, kernel compilation and video encoding:


Same with text at the bottom indicating which computer is strong in which domain (also has black+white for printing):
http://www.cons.org/cracauer/crabench/core2.user.html

The top bars are the Conroe, times are relative to a socket 939 Opteron at 2.6 GHz with 220 MHz memory. Times not complete yet but I might get to sleep before it completes, so here's what I have:

I know the numbers look disappointing for now but keep in mind this is non-overclocked and the Opteron at 3.08 GHz is not only overclocked, it has it's memory running at 300+ MHz which is higher than the DDR2 here for now, and that Opteron is single-core, the Conroe is dual-core.

Nontheless. For what is most important for me, compiling programs, this CPU is only 15% faster at the same clockspeed than a dual-core Opteron 939 (2.4 GHz Conroe is 5% faster than 2.6 GHz Opteron).

The benchmarks are not tuned towards either processor. It's running FreeBSD-6.0beta4 32 bit, SMP kernel. Everything compiled with generic compiler options that go for all processors, with the exception of the second run of mplayer (a video encoder), which first runs generic, then benchmarks how fast it recompiles itself to a specialized version, then runs the specialized version. You can move this harddrive between computers as you like (in fact that is how I run the benchmark suite).

More information about the benchmark is here:
http://forum.useless-microoptimizati.../crabench.html

The FAQ has all the info on individual benchmarks run here, more results are there or linked to, and the sourcecode for everything can be downloaded there.

I am working on a 64 bit version, which will also be much heavier on the multi-threaded benchmarks than this one.

I'll update this thread as more results come in. A single run through my suite takes 12 hours and I won't be home tomorrow so be patient.

The setup has watercooling and 2x 1 GB DDR2-1000 Super Talent (the stuff Fugger was raving about), so overclocked results should appear soon.

If you have any question please feel free to ask. Do not ask to get the CPU, I gave a harddrive with a copy of my benchmarks to a person running it for me and I fetch the results as they are computed.

[uOpt]

Chart above is now updated with results at 3.0 GHz, memory scaled accordingly.

Now that's more like it. Still default Vcore.

[uOpt]

Chart updated with results at 3.66 GHz.

Required Vcore raise from 1.40 to 1.45. Duh

[Silver Bullet]

results look pretty much like windows i'd say .. conroe wins

[uOpt]

yeah, really no surprises here.

Performance is about what is execpected relative to AMD64 at the same clockspeed. C/C++ compilation is somewhat disappointing, though.

But these chips overclock like mad.

It is almost certainly possible to bang this E6600 right to the FSB limit of the board without exhausting the chip. Time for floppies from ITK I guess.

Power consumption goes through the roof, though. Dual-priming 3765 MHz at 1.500 Vcore gets right up to 277 Watts for a naked system with no drives other than a notebook HD, waterpump and a GeForce 5200 in 2D. Dual-Core Opterons at high volts at 2.8 GHz go to 245 or somesuch in a similar setup.

[h@RRy]

Amazing...

Great work u(Opt) Now THIS is what I call benching.

[Theta]

Amazing...

Great work u(Opt) Now THIS is what I call benching.

Agreed, I love your bench results setup! Very nice touch keeping the FX-60 as constant in the charts - really gives a quick review of how badly it's getting smoked.

[[XC] moddolicous]

Sorry for the bump, but these are some good results Uopt. I think you'll need a dual woodcrest board to compare to your Opty 875 rig.

[AndrewZorn]

I can't believe it beats the Opteron by that much in real-world...

[Lestat]

man andrew where have you been for the last 2 months ?

the conroe kicks the living sh|t out of nything amd has, and anything amd is going to release for the next 6-9 months..


King Conroe lives!!!

and btw.. who gives a crap about unix... sorry uOpt linux or anything *nix is just a waste of time.(let the hate fly for me saying that from all you nix nerds.)

i cant believe you can even run anything *Nix on an intel 975x i cant believe it even loads...

[Lestat]

and yes im just giving you a hard time..

except about being surprised it even loads on a 975x board. that i am shocked about. nix is always 6 months behind on hardware, or more.

[DsM]

good job on the benchmarks....

interesting subject about *nix though... the statistical programs i have to use to handle large amounts of data from economic firms, corps, etc run better on unix based OS's... i dont know why specifically... i find windows to be bloated.. dont get me wrong.. i use windows on my home gaming machine as i do enjoy gaming and as of this time... it's still not easily do-able in *nix.... I have to say I do like not having to re-activate linux when i change hardware out too many times, or even better.... having to pay for the OS to leagaly use it....

[uOpt]

I should mention that I posted some more specialized appliction results in the 64 code thread that show even more of an advantage for Conroe.

ETA: here:
http://www.xtremesystems.org/forums/...d.php?t=104646

[agenda2005]

I should mention that I posted some more specialized appliction results in the 64 code thread that show even more of an advantage for Conroe.

uOpt,
Please can you run this SPEC 2000 benchmark, 188.ammp (www.spec.org) with both CONROE and Opty at 3.0GHz using SSE/SSE2/SSE3 compilation flag on 64 bit Linux.

If you have an Intel compiler, that will be appreciated, but gcc is okay.

I know results are on SPEC website, but most of them are for woodcrest using FB DIMMS at CL5.

[uOpt]

The SPECint benchmarks are mostly toys in my opinion. Much too small data size to be realistic. It's all cache games with them. In particular, there is no way you will see a meaningful difference between FB-DIMMs at 533 MHz and my unbiffered 1000 MHz Supertalent megagigaheckiheckipanteng memory since SPECint never hits the memory. It also is the reason why Netburst looked decently in SPECint when real-world apps other than encryption, encoding and a few other simple-code things usually failed miserably.

In fact SPECint is the major reason that I wrote my own benchmark suite. SPECfp might be OK.

I am working on an update. The update will have:

• Fullly recompilable applications so that you can use any compiler and optimization flags you like
• Benchmark distribution entirely lives in a 32 bit Linux chroot-able environment that can run (binary code run) in Linux/i386, Linux/amd64, FreeBSD/i386 and FreeBSD/amd64. Since all is retargettable (see point 1) you can take the target runs to the surrounding environment, that means 64 native code, either with the surrounding platform compiler or with any compiler of your choice
• Free of copyrighted material
• More concurrency benchmarks, higher workloads to stress 32+ CPU machines if requested, more mixtures of benchmarks
• md5 checksumming of results, namely of the videos, to notify user of memory corruption not shown in compilation
• Hopefully some real multithreaded code but that is hard to come by and hard to measure, the current concurrency framework might do

[agenda2005]

The SPECint benchmarks are mostly toys in my opinion. Much too small data size to be realistic. It's all cache games with them. In particular, there is no way you will see a meaningful difference between FB-DIMMs at 533 MHz and my unbiffered 1000 MHz Supertalent megagigaheckiheckipanteng memory since SPECint never hits the memory. It also is the reason why Netburst looked decently in SPECint when real-world apps other than encryption, encoding and a few other simple-code things usually failed miserably.

In fact SPECint is the major reason that I wrote my own benchmark suite. SPECfp might be OK.

I am working on an update. The update will have:

• Fullly recompilable applications so that you can use any compiler and optimization flags you like
• Benchmark distribution entirely lives in a 32 bit Linux chroot-able environment that can run (binary code run) in Linux/i386, Linux/amd64, FreeBSD/i386 and FreeBSD/amd64. Since all is retargettable (see point 1) you can take the target runs to the surrounding environment, that means 64 native code, either with the surrounding platform compiler or with any compiler of your choice
• Free of copyrighted material
• More concurrency benchmarks, higher workloads to stress 32+ CPU machines if requested, more mixtures of benchmarks
• md5 checksumming of results, namely of the videos, to notify user of memory corruption not shown in compilation
• Hopefully some real multithreaded code but that is hard to come by and hard to measure, the current concurrency framework might do

Thanks.
Which of your benchmark suit is highly branched?

Branch misprediction is what I care about most.

I want to see how Intel new marco op fusion help with this problem and that all depend on if there is a compilation flag required or just an hardware aware operation.

The benchmark that I requested specifically is a SPECfp (188.ammp) and it uses over 200MB of memory. I will appreciate if you can do it for me.

[uOpt]

As I said, the SPECfp stuff should be OK at least. I also spotted they kicked that absurdity xlisp part out of SPEC, that's certainly a good sign.

I'll run some of it next round.

The Lisp benchmarks in my suite are certainly very unpredictable, CMUCL compiled code is a master when it comes to throwing branch prediction and it definitely violates every single branch prediction helper item in the Netburst-area ia32 optimization manual (the code runs nice otherwise, though).

Depending on license I can integrate all the SPEC stuff in runs of my suite but I doubt it's that easy.

[uOpt]

The chart above has been updated with a run while setting memory to 600 MHz (400 MHz BIOS * 1.50) with the 1066 strap, instead of the 800. Lower wouldn't do, I don't get a post at 333 MHz * 1.50.

As you can see, going down from 800 to 600 MHz makes few difference unless you do low-quality video.

Should do a run with some other timings and same frequency.

[THE JEW (RaVeN)]

Thanks for the results. Maybe submit them to Linux Hardware or Phoronix? They might be willing to pay ya something for 'em.