CPU IV+ , SPARC64 VI and SPARC64 VII

Hi,

are there any documentation about benchmarks on that above mentioned CPUs?

Any other hints to take care about SPARC64-CPUs versus IV+?

Regards,
Heinz

Heinz Müller wrote:
> Hi,
>
> are there any documentation about benchmarks on that above mentioned CPUs?
>
> Any other hints to take care about SPARC64-CPUs versus IV+?
>
> Regards,
> Heinz
>
>
You may take a look at
http://www.spec.org/cgi-bin/osgresults?conf=cpu2006 and search for
processors with "sparc" in their name.

The brand new SPARC64 VII seems to increase the single CPU performance
only because of it's slightly increased MHz, compared to SPARC 64 IV.

The throughput benchmarks show, that compared to the Sun 490/890 with
SPARC IV+ there is no great improvement for equal equipped boxes.

Hi,

for my understanding:

Taking the CINT2006 Rates bench the V490 has got 78.0 (Result)
and the M5000 from May 2007 has got 158.

Have I to divide the results with the number of cores to get
a good speed comparision?

For example 78/8 and 158/16 ??

Do you know the meaning of the column baseline?

Heinz
CINT2006 Rates
"Frank Langelage" <> schrieb im Newsbeitrag
news:...
> You may take a look at http://www.spec.org/cgi-bin/osgresults?conf=cpu2006
> and search for processors with "sparc" in their name.
>
> The brand new SPARC64 VII seems to increase the single CPU performance
> only because of it's slightly increased MHz, compared to SPARC 64 IV.
>
> The throughput benchmarks show, that compared to the Sun 490/890 with
> SPARC IV+ there is no great improvement for equal equipped boxes.

Heinz Müller wrote:
> Hi,
>
> for my understanding:
>
> Taking the CINT2006 Rates bench the V490 has got 78.0 (Result)
> and the M5000 from May 2007 has got 158.
>
> Have I to divide the results with the number of cores to get
> a good speed comparision?
>
> For example 78/8 and 158/16 ??
>
> Do you know the meaning of the column baseline?
>
> Heinz
> CINT2006 Rates
> "Frank Langelage" <> schrieb im Newsbeitrag
> news:...
>> You may take a look at http://www.spec.org/cgi-bin/osgresults?conf=cpu2006
>> and search for processors with "sparc" in their name.
>>
>> The brand new SPARC64 VII seems to increase the single CPU performance
>> only because of it's slightly increased MHz, compared to SPARC 64 IV.
>>
>> The throughput benchmarks show, that compared to the Sun 490/890 with
>> SPARC IV+ there is no great improvement for equal equipped boxes.
>
>

To give an impression of the performance of a single CPU the CINT2006
(integer) and CFP2006 (floating point) are designed to use.

The CINT2006 Rates and CFP2006 Rates are designed to show the throughput
of a multi CPU system. Therefore similar systems with different number
of CPUs are benchmarked to show the increase of power with additional
CPUs (how much more power for twice the number of CPUs?).
So dividing this throughput value by the number of CPUs is not really fair.
If you want to do this, compare equal equipped boxes:
- SUN Fire V890 (8 dual core CPU) with M5000: 154 / 158 -> identical
- SUN Fire 490 (4 x dual core) with M4000: 78 / 81.6 -> nearly identical.
For comparison, the price of the systems should be taken into account,
but unfortunately this is not delivered with the benchmark protocol.
Then we could see, how much more power the new Mx000 with SPARC64 VII
quad core CPUs give us for the same money.

Baseline means, that only a limited number of compiler flags where used
and no feedback optimization was used.
SPEC 2006 CPU is delivered in C/C++ source and compiled on the machine
the benchmark is executed on. All compiler flags, the operating system
version, the compiler et cetera are documented as you can see when
clicking on the links on the right.

"Heinz M?ller" <> wrote:
> Taking the CINT2006 Rates bench the V490 has got 78.0 (Result) and
> the M5000 from May 2007 has got 158.

> Have I to divide the results with the number of cores to get a good
> speed comparision?

> For example 78/8 and 158/16 ??

Only if you are willing to ass-u-me the system scales perfectly on the
SPECint_rate2006 workload. Many systems will scale very well for some
definition of "very well" and others do not. If you can find rate
results for different numbers of copies on the same hardware/system
you can try to use that to see how close to "very well"
SPECint_rate2006 scales there.

Given that it is rare to see superlinear scaling on SPECint_rate2006,
if you simply divide the result at N copies by N you should arrive at
a pessimistic estimate for the performance/speed of a single copy rate
running the binaries used to produce the N copy result. However, in
reality a single copy _may_ run (slightly) faster. Lots of variables
involved - is the system single threaded cores or lots of HW threading
involved, shared vs unshared caches, etc etc...

On a slightly related drift... one can flip back and forth between a
"speed" run and a 1-copy "rate" run:

http://www.spec.org/cpu2006/Docs/run...tml#rule_4.3.2

With the caveat that binaries used in a rate result are rarely
compiled auto-parallel. Just keep that in mind when converting and
then trying to contrast with other/published speed metrics.

I'd be especially careful doing that after a divide by N exercise,
especially one involving a heavily threaded system. At least that is
my gut instinct - it is making an estimate from an estimate. Better to
press the vendor(s) for a single-copy rate run or a non-auto-parallel
speed metric.

> Do you know the meaning of the column baseline?

http://www.spec.org/ and the CPU2006 docs/faq probably has lots on
that topic. For example:

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

rick jones
--
denial, anger, bargaining, depression, acceptance, rebirth...
where do you want to be today?
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...