opteron VS Itanium 2
rbw at ahpcrc.org
Thu Oct 30 12:28:45 EST 2003
On Thu, 30 Oct 2003 12:00:54, Mark Hahn wrote:
>> Of course, there is some truth to what you say, but "this says nothing about
>> It2" seems a tad dramatic (but ... definitely in character ... ;-) ). Below is
>all the world's a stage ;)
Life without drama is life without the pursuit of happiness ... ;-).
>> the memory table for most of the benchmarks. A few fit in the 6MB cache (although
>> some surely should, as some codes do or can be made too fit into cache). Many
>seriously, the memory access patterns of very few apps are uniform
>across their rss. I probably should have said "working set fits in 6M".
Good point, most memory accesses are not globally stride-one. But of course
this fact leads us back to the idea that cache >>is<< important for a suite
of "representative codes".
>and you're right; I just reread the spec blurb, and their aim was 100-200MB.
>> are in the 100 to 200 MB range. The floating point accumen of the I2 chip is hard
>that's max rss; it's certainly an upper bound on working set size,
>but definitely not a good estimator.
Yes, an upper bound. We would need more data on the Spec codes to know
if the working sets are mostly sitting in the I2 cache. There is an
inevitable dynamism here with larger caches swallowing up larger and larger
chunks of the "average code's" working set and while the average working
set grows over time.
>in other words, it tells you something about the peak number of pages that
>the app ever touches. it doesn't tell you whether 95% of those pages are
>never touched again, or whether the app only touches 1 cacheline per page.
>in yet other words, max rss is relevant to swapping, not cache behavior.
You might also say it this way ... cache-exceeding, max-RSS magnitude by
itself does guarantee the elimination of unwanted cache effects.
>> And after all a huge cache does raise the average memory bandwidth felt by the
>> average code ... ;-) (even as average codes sizes grow) ... and a large node count
>even though Spec uses geo-mean, it can strongly be influenced by outliers,
>as we've all seen with Sun's dramatic "performance improvements" ;)
>in particular, 179.art is a good example. I actually picked it out by
>comparing the specFP barchart for mckinley vs madison - it shows a fairly
>dramatic improvement. this *could* be due to compiler improvements,
>but given that 179.art has a peak RSS of 3.7MB, I think there's a real
>cache effect here.
I agree again, but would say that such a suite as SpecFP should
include some codes that yield to cache-effects because some real
world codes do.
Always learn or am reminded of something from your posts Mark ... keep on
keeping us honest and true ;-) like a Canadian Mountie.
Beowulf mailing list, Beowulf at beowulf.org
To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
More information about the Beowulf