opteron VS Itanium 2

Richard Walsh 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 mailing list