Jump to content
The Inquirer-Home

Sandra 2009 sizes up the chip competition

GPGPU Watch All the (G)flops
Monday, 1 September 2008, 09:11

OUR BRITISH friends behind the famed Sandra benchmark suite, are putting in some serious work to push forward the suite in face of the increasing competition like Everest and such.

After all, Sisoftware Sandra has been popular for a long time due to its rich graphics, multitude of CPU, memory and I/O tests, as well as easy-to-create summary reports in a variety of formats.

alt='sandralogo'

The upcoming Sandra 2009 promises a lot more, and we've been running its beta over the past few weeks - yeah, the one in Original (British) English flavour.

Besides getting some record results on the 2.66 GHz 4-socket 24-core Dunnington demo box at IDF (how does 300,000 MIPS and 230 GFLOPs in double precision sound?) the new Sandra also shows some truly good NUMA-optimised dual socket Gainestown Nehalem memory bandwidth numbers on the Tylersburg platform, exactly thrice that of the dual socket Skulltrail.

All this pales in comparison to something else Sandra can do: it is the first combined CPU and GPU computational throughput benchmark we're aware of - with nice comparison graphs to boot. Even the beta version is stable - so expect the final one very soon.

We put together a simple configuration, using a 3.2 GHz QX9650 Asus Striker Extreme X48 setup with 8GB RAM of DDR3-1600 Kingston memory and Windoze Vista 64-bit SP1.

We ran a spread of the most recent graphics cards on the Nvidia side, Asus GTX280 TOP and Leadtek GTX260, as well as the older Asus 9800GTX TOP (same speeds as the current 9800GTX+) and 9800GX2 dual GPU monster. The GPUs were all run at factory settings here.

So, how does the ultimate PC, a total of four 3.2GHz cores, compare with the GPUs in this - highly synthetic, mind you - Mandelbrot comparison using the new 'pixels per second' measure? Here are the screen shots:

alt='sancpumm9650'

vs the GPUs:

alt='sannvgpu'

Finally, the current version couldn't run on the AMD cards under Vista64 - we'll fix a separate test run on XP64 instead for this purpose. In the meantime, look how the Nforce GTX280 compares to the reference AMD graphics cards provided by Sandra. Strange, this is an obnoxiously high advantage for Nvidia over the cards that all have a theoretical GFLOPs advantage over it - 2.5x in the case of 4870X2, for instance.

alt='sannvgpuvsatinew'

alt='sannv260mem'

Coming back to the results, as you can see, Sandra bandwidth results correspond nicely to the vendor's claimed GPU memory bandwidth minus some overhead. The numbers, in excess of 80GB/s for GTX260 and dual 4870, show how far things go. If the run passed fine on the GTX280 TOP, it'd have exceeded 100GB/s handily.

As for the computational numbers in this Mandelbrot run, well look at it this way: hundreds of Mpixels for CPU vs Gpixels for the GPU - says it all.

Once the release version is out, we'll be showing the complete NV vs ATI GPU computation and memory benchmarks - in the meantime, enjoy the early peep at t he scores! ยต

Share this:

Comments
Mandelbrot is a bad benchmark

Mandelbrot is a pretty stupid benchmark since it is pretty GPU processing friendly and the amount of data througput is neglictable. Have a benchmark that needs lot of scattered memory read/writes and conditional branching or lots of large datasets and your GPU speed drops close to zero

posted by : DrBalthar, 01 September 2008 Complain about this comment
Nothing here to see, move along

Even more unusable than Vantage. Hardly gives any info regarding to real world application performance. Why bother with this one?

posted by : Manteli, 01 September 2008 Complain about this comment
it all depends on the point of view

here , it is benchmark throwing numbers for numbers, no real use of those benchmarks ...
Let's take an example ... a Core 2 is capable of 600GB/s .. from L1 to loads units ... That is much better than any GPU ... I just forgot to tell you that it is only using the dice cache L1/L2 ... Those kind of number are so easy to manipulate that it makes them totally useless.

This benchmark totally forget to tell you that the GPU has to send the data back through PCIexpress, and the "way back" on PCIex is 1X ...Extremely slow: 132 MB/s ... what is the point of having so much bandwitch on the GPU boards, except using it for outputting on the screen? any other usage has to go back to CPU at 132 MB/s ... snail speed!

Let's stop throwing at people numbers, and let's give them a better vision of the performance gain with main stream application.

Francois

posted by : Francois, 01 September 2008 Complain about this comment
correction ...

PCIexpress 1x back is 250Mb/s ...
almost 2 times snail speed!

posted by : Francois, 01 September 2008 Complain about this comment
Pick the right tool

DrBalthar, you mean to tel me this is yet another meaningless metric that shows that GPUs are good at some problems and CPUs others? And the appropriate solution is to choose the right tool for the task?

Shocking.

posted by : PeterPan, 01 September 2008 Complain about this comment
I Pity Fool Who Dosn't Engineer for TOP End.

In Memorial for Late, Great Mr. T, "I Pity Fool Whom Dosn't Use Ultimate 64".

It may be Shaft, Yet when explored half year ago, surprise was that half dozen breadboards did work as well as xp(Barf)64.

Here it is Not Blather to warn, Once Again engineers could NOT Handle simple task of making system compatible with Most Powerful Retail desktop O/S. Ultee'64.

Next, Naj. Find system that will play Vista Ultimate 64 with parts acquired, it'll be HOT as Nvidia g96s' or even Hotter for warrentable Retail Market.

Using Dead O/S isn't Incisive Writing.
drashek

posted by : Instructor_Blather, 01 September 2008 Complain about this comment
Good point DrBalthar

It's too bad that the Inq can't realize that if you expose that great upcoming throughput CPU they seem to love so much to the same situation that DrBalthar suggested it's performance would also drop similarly.

posted by : x86_64, 02 September 2008 Complain about this comment
Do those tests really show anything ?

Or have I missed something ?
Always thought comparing MIPS to GFLOPS to pixels/sec is like comparing apples and bananas to baked bacon.
Highly specialized functions always run best on highly specialized software written for highly specialized hardware.
Quite a step back for Sandra, they had quite a good suite for average comparisations and anyone not having an "avarage" system will surely not need them for testing their speed.

posted by : WoenK, 02 September 2008 Complain about this comment
Advertisement
Subscribe to the INQ Newsletter
Sign-up for the INQBot weekly newsletter
Click here to sign up Existing user
Advertisement
INQ Poll

Christmas computer sales

Will you be buying a new computer this Christmas?