Subject: Re: Athlon SDR/DDR stats for *specific* gaussian98 jobs (fwd)

From: Eugene Leitl <[email-masked]>
Date: Wed, 2 May 2001 19:52:06 +0200 (MET DST)

---------- Forwarded message ----------
Date: Wed, 2 May 2001 12:53:17 -0400 (EDT)
From: Mark Hahn <[email-masked]>
To: Velocet <[email-masked]>
Cc: [email-masked]
Subject: Re: Athlon SDR/DDR stats for *specific* gaussian98 jobs

> the same duron on a DDR board w/256Mb DDR RAM (talk about a waste! :)

well, a duron has the same dram performance as a tbird at the same FSB.
so in that sense, it's actually a better match for a lot of computational
codes that sneer at cache.

otoh, tbirds are dirt cheap, not much more than durons.

> I havent had a chance to run any of these on a P4 with SSE3 (is that the

sse2.  gcc 3.0 snapshots apparently can generate sse2 code...

> in contributing such stats I'm very interested.) My stats here were generated
> with ATLAS compiled for each change in config.

does ATLAS include prefetching?  it's fairly astonishing how big a
difference prefetching (and movntq) can make on duron/athlon code.
for an extreme case (Arjan van de Ven's optimized page-copy and -zero):

600.044 MHz
clear_page 'normal_clear_page'  took 8429 cycles (278.0 MB/s)
clear_page 'slow_zero_page'     took 8451 cycles (277.3 MB/s)
clear_page 'fast_clear_page'    took 7341 cycles (319.3 MB/s)
clear_page 'faster_clear_page'  took 2576 cycles (909.7 MB/s)
clear_page 'even_faster_clear'  took 2573 cycles (910.8 MB/s)

copy_page 'normal_copy_page'    took 8237 cycles (284.5 MB/s)
copy_page 'slow_copy_page'      took 8238 cycles (284.5 MB/s)
copy_page 'fast_copy_page'      took 5798 cycles (404.2 MB/s)
copy_page 'faster_copy'         took 3046 cycles (769.3 MB/s)
copy_page 'even_faster'         took 3077 cycles (761.6 MB/s)

that's on a duron/600 (100 ddr fsb), kt133, cas2 PC133.
I haven't seen results from a ddr dram system yet.

> There are some caveats and other environmental factors discussed on
> the page as well.

error bars would be nice.

> I am not trying to start a jihad here against high speed Thunderbird
> and Dual Thunderbird proponents; this is just what i've found for *MY*

maybe I'm being dense, but how would these results be interpreted
jihadically?  in general, they show two things: high-end machines
bear a price-premium that decreases their speed/cost merit, and
that freebsd's page coloring sometimes has a measurable benefit.

I'm dubious about further interpretation, though.  for instance,
you seem to show a significant benefit to tbird's larger cache
(384 vs 192K), but surely you chose this workload to be bandwidth
intensive, didn't you?  if not, then the DDR comparison is rather
specious...

thanks for posting the numbers!

regards, mark hahn.

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