Memory Performance Issue with Fedora Core 2 Kernels

[Fritz Whittington]

On or about 2004-08-01 18:55, James Wilkinson whipped out a trusty #2 
pencil and scribbled:

>I wrote (about 4G/4G)
>  
>
>>The basic trade-off that 4G/4G flushes
>>the TLB each context switch, so that kernel and user both get
>>nearly 4 GB, and TLB flushes are expensive.
>>    
>>
>
>Gene Heskett replied:
>  
>
>>Ouch!  Does this help explain why my old mobo runnng a 1400XP athlon 
>>could do 4.5 seti nits a day, and a 2800XP with this turned on is 
>>only doing 6?
>>    
>>
>
>Possibly. However, I don't think the SETI client does many context
>switches (except when it's hitting the network to send results and
>retrieve a new work unit). It should be all user-land calculation.
>
>Besides, IIRC, they never produced a 1400 XP. There was a 1400 MHz
>"Thunderbird" design Athlon, then after a couple of redesigns, AMD
>came up with the 2800+ "Barton" Athlon, which *was* labelled XP.
>
>Those redesigns were aimed at getting more performance "per clock"
>(per MHz) out of the Athlon, rather than increasing the frequency,
>and they normally worked. AMD had (has) a fairly neutral benchmark
>which they used to calculate the processor rating: even though the
>2800+ only runs at 2.083 GHz, it's supposed to be twice as fast as
>a 1400 MHz Thunderbird -- on "average" Windows apps.
>
>But I understood SETI to be dependent more on memory speed than on
>the efficiency of the processor once the data has reached it (with
>modern processors).
>
>On the third hand, I understood that a SETI work unit was supposed
>to be around 340 K, which should fit into Barton's 512 K cache (if
>not into Thunderbird's 256 K). That should mean the Barton doesn't
>have to go back to main memory for SETI data, which should (again)
>make it much faster. Perhaps SETI have changed the work unit size.
>
>So I'm not sure exactly why you're seeing those figures. You could
>try compiling a vanilla 2.6.7 kernel and see what happens.
>
>James.
>  
>
In my experience, SETI is also extremely dependent on the quality of the 
FPU, and Intel FPUs have traditionally been quite a bit faster than 
AMD.  In their efforts to improve the "typical Windows" app execution, 
AMD may have given the FPU the short end.  This is based on observations 
from about 3 years ago, I don't have any of the really recent AMD 
systems to compare.

-- 
Fritz Whittington
TI Alum - http://www.tialumni.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3252 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-list/attachments/20040802/3aeb9f66/attachment-0001.bin>