[RC5] Speed

gindrup at okway.okstate.edu gindrup at okway.okstate.edu
Tue Apr 21 20:25:09 EDT 1998


     The number you quote is not intrinsically meaningful.  The D.Net 
     distributed effort isn't doing any floating point.  The number is an 
     estimate, and (honestly) a pretty crude one.  Not all of the x86s in 
     the effort are P5/100s, nor are the PPCs all 604e/200s, et c.
     
     This means that the estimate given may be wildly inaccurate.
     
     The method used to generate this number was to take the known number 
     of blocks reported by processor class and divide by a known standard 
     reference processor in that class.  All this does is represent the 
     class of rotation and integer operation performing processors by a 
     single processor.  For the RC5 algorithm, the known block output of 
     the effort is the same as if <insert number> P5/100s and <insert 
     number> PPC 604e/200s and et c. processors were working on the 
     effort.  This gives a very poor estimate of how many of each of 
     these processors would be needed to perform a certain number of 
     FLOPS.
     
     The number of representatives generated by that chart only indicates 
     how the class of processors is doing using a particular member as a 
     meter stick.  For measuring the RC5-ops, this measure is extremely 
     good.  For measuring tight-loop shifting and integer unit 
     operations, it is fair.  For measuring FLOPS, it is terrible.
     
     The class of x86 processors, e.g., probably does not "scale" to 
     FPU-intensive operation the same was as the representative (P5/100). 
      If the population of x86 processors does operate particularly like 
     a large number of P5/100s (hah!) the estimate of FLOPS would be 
     meaningful.
     
     Remember, one of the best x86-class processors to use on RC5 is the 
     AMD K5.  The K5 has pretty lousy relative FPU performance (compared 
     to, say, the AMD K6).
     
     So let's imagine that the RC5 algorithms suddenly became 
     FPU-intensive overnight.  Then, the number of blocks returned by the 
     x86-class processors will change and the "standard" number of blocks 
     returned by a P5/100 will change.  It is exceedingly unlikely that 
     these numbers will change in a way that the apparent number of 
     P5/100-equivalents in the x86-class is unchanged from today.  Thus, 
     the FLOPS estimate would change and I would expect it to change 
     radically.
     
     Therefore, although there is a number called "FLOPS" on the chart, I 
     wouldn't expect it to mean very much.  The only way to get a 
     meaningful FLOPS measurement on the D.Net computer would be to 
     actually start doing FPU operations with it and then see how it 
     does.
            -- Eric Gindrup ! gindrup at okway.okstate.edu


______________________________ Reply Separator _________________________________
Subject: [RC5] Speed 
Author:  <rc5 at llamas.net> at SMTP
Date:    4/20/98 11:35 AM


Some of you will remember that a month or so ago I asked the question of 
Flops that D.Net has.  I got my answer today.  Combined MFlops are : 
2959855 or at least that is what it says on the stats page (thumbs up for 
new look).  That I think officially makes us the fastest computer on the 
net.
        Also, is it possible that someone from the admin write a letter to 
the magazine byte and tell them that they are wrong (the said that 
fastest computer has broken 1 terraflops).
     
Thank you again for your time...
        Bojan Baros
     
--
To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net 
rc5-digest subscribers replace rc5 with rc5-digest
     
     


--
To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest



More information about the rc5 mailing list