Off topic - G5 question

[Mark Hahn]

> unit represents filled.  It actually looked like a thoughtful
> architecture at least at the block device/bus level.

it's dandy.  the problem is Apple's marketing nonsense.

SIMD is great, too.  cache is great.  but please don't claim that your 
in-cache SIMD FLOPS is a general/true FLOPS rate for the machine,
since it's NOT, for anything other than Mandelbrot surfing.

incidentally, I don't see *any* off-chip cache in the G5's.

> Of course, this makes a LOT of things very difficult to properly
> benchmark.

I don't agree at all.  I want to see precisely two sets of numbers
when evaluating new hardware performance:

	- fairly clean microbenchmarks like Stream, streaming
	sequential file IO, zero-byte packet latency, etc.

	- best-case performance on real codes - for the compute
	cluster world, that means SpecFP and SpecFPrate.  other fields
	may want tuned-BLAS or 45-filter photoshop.

well, and price, but that's normally boringly predictable 
(I say "way too expensive!" a lot ;)

> suck on it.  Also one needs to use SSE2 instrumented compilers and
> instructions to get fair comparisons from alternative architectures, for

I find that many of my users spend most of their serious time inside
tuned library functions, so the compiler is less relevant.  though Intel's
compilers *do* auto-vectorize onto SSE2.  gcc can use SSE2, but doesn't
currently autovectorize.  incidentally, gcc 3.3 *does* also support 
intrinsics for Altivec vector operations; I'm not sure whether similar 
intrinsics are available for SSE2.

> flags on both systems works for me, at least, as this is likely to be
> the extent of the effort I want to make tuning per architecture, ever.

I find this irresponsible (sorry rgb!).  if you're going to consume 
more than a few CPU hours, and those cycles are coming from a shared 
resource, failing to optimize is just plain hostile.

I still see users fling their code at a machine with 
	g77 prog.f && ./a.out
and wonder why it's so slow.  usually, I stifle the obvious answer,
and (hey, this is Canada) apologize for not providing the information
they need to make supra-moronic use of the machine...

regards, mark 'surly' hahn.


_______________________________________________
Beowulf mailing list, Beowulf at beowulf.org
To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf