lkml.org 
[lkml]   [2003]   [Feb]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Minutes from Feb 21 LSE Call
On Sun, Feb 23, 2003 at 06:54:41PM -0800, Linus Torvalds wrote:
>
> On Sun, 23 Feb 2003, David Mosberger wrote:
> > >> 2 GHz Xeon: 701 SPECint
> > >> 1 GHz Itanium 2: 810 SPECint
> >
> > >> That is, Itanium 2 is 15% faster.
> >
> > Unfortunately, HP doesn't sell 1.5MB/1GHz Itanium 2 workstations, but
> > we can do some educated guessing:
> >
> > 1GHz Itanium 2, 3MB cache: 810 SPECint
> > 900MHz Itanium 2, 1.5MB cache: 674 SPECint
> >
> > Assuming pure frequency scaling, a 1GHz/1.5MB Itanium 2 would get
> > around 750 SPECint. In reality, it would get slightly less, but most
> > likely substantially more than 701.
>
> And as Dean pointed out:
>
> 2Ghz Xeon MP with 2MB L3 cache: 842 SPECint
>
> In other words, the P4 eats the Itanium for breakfast even if you limit it
> to 2GHz due to some "process" rule.
>
> And if you don't make up any silly rules, but simply look at "what's
> available today", you get
>
> 2.8Ghz Xeon MP with 2MB L3 cache: 907 SPECint
>
> or even better (much cheaper CPUs):
>
> 3.06 GHz P4 with 512kB L2 cache: 1074 SPECint
> AMD Athlon XP 2800+: 933 SPECint
>
> These are systems that you can buy today. With _less_ cache, and clearly
> much higher performance (the difference between the best-performing
> published ia-64 and the best P4 on specint, the P4 is 32% faster. Even
> with the "you can only run the P4 at 2GHz because that is all it ever ran
> at in 0.18" thing the ia-64 falls behind.

I agree, especially the cache difference makes any comparison not
interesting to my eyes (it's similar to running dbench with different
pagecache sizes and comparing the results). But I've a side note on
these matters in favour of the 64bit platforms. I could be wrong, but
AFIK some of the specint testcases generates a double data memory
footprint if compiled 64bit, so I guess some of the testcases should be
really called speclong and not specint. (however I don't think those
testcases alone can explain a global 32% difference, but still there
would be some difference in favour of the 32bit platform)

So in short, I currently believe specint is not a good benchmark to
compare a 64bit cpu to a 32bit cpu, 64bit can only lose in specint if
the cpu is exactly the same but only the data 'longs' are changed to
64bit. To do a real fair comparison one should first change the source
replacing every "long" with either a "long long" or an "int", only then
it will be fair to compare specint results between 32bit and 64bit cpus.

I never used specint myself, so don't ask me more details on this, and
again I could be wrong, but really - if I'm right - somebody should go
over the source and make a kind of unofficial (but official) patch
available to people to generate a specint testsuite usable to compare
32bit with 64bit results, or lots of effort will be wasted by people
pretending to do the impossible. I mean, if the memory bus is the same
hardware in both the 32bit and 64bit runs, the double memory footprint
will run slower and there's nothing the OS or the hardware can do about
it (and dozen mbytes of ram won't fit in l1 cache, not even on the
itanium 8). The benchmark suite really must be fixed to ensure the 32bit
and 64bit compilation will generate the same _data_ memory footprint if
one wants to make comparisons between the two.

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:33    [W:0.072 / U:1.648 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site