Author: Vincent Diepeveen
Date: 04:20:50 07/16/03
Go up one level in this thread
On July 16, 2003 at 00:44:34, Keith Evans wrote: >On July 16, 2003 at 00:29:43, Robert Hyatt wrote: > >>On July 16, 2003 at 00:05:29, Keith Evans wrote: >> >>>On July 15, 2003 at 23:35:30, Robert Hyatt wrote: >>> >>>>On July 15, 2003 at 23:05:37, Vincent Diepeveen wrote: >>>> >>>>> >>>>> >>>>>Now i can disproof again the 130ns figure that Bob keeps giving here for dual >>>>>machines and something even faster than that for single cpu (up to 60ns or >>>>>something). Then i'm sure he'll be modifying soon his statement something like >>>>>to "that it is not interesting to know the time of a hashtable lookup, because >>>>>that is not interesting to know; instead the only scientific intersting thing is >>>>>to know is how much bandwidth a machine can actually achieve". >>>>> >>>> >>>> >>>>What is _interesting_ is the fact that you are incapable of even recalling >>>>the numbers I posted. >>>> >>>>to wit: >>>> >>>>dual xeon 2.8ghz, 400mhz FSB. 149ns latency >>>> >>>>PIII/750 laptop, SDRAM. 125ns. >>>> >>>>Aaron posted the 60+ ns numbers for his overclocked athlon. I assume his >>>>numbers are as accurate as mine since he _did_ run lm_bench, rather than >>>>something with potential bugs. >>>> >>>>I can post bandwidth numbers if you want, but that has nothing to do with >>>>latency, as those of us understanding architecture already know. >>>> >>> >>>Can you run lmbench and give the latency numbers for different stride sizes? >>>Then you could quote numbers from cache,... >>> >> >>Here's my laptop data. L1 seems to be 4 clocks. L2 9 clocks, memory >>at 130ns. This is a PIII/750mhs machine with SDRAM. I just ran it again >>to produce these numbers. >> >> >> >>Host OS Mhz L1 $ L2 $ Main mem Guesses >>--------- ------------- --- ---- ---- -------- ------- >>scrappy Linux 2.4.20 744 4.0370 9.4300 130.2 >> >>>In the lmbench paper they have a nice graph like this. >> >> >>Is the above what you want? > >I think that it's as close as you're going to get. The most important thing is >that 130 [ns] is the largest number. And wouldn't that be a little bit >pessimistic even for chess hash tables? this is optimistic, because those latency numbers are sequential latency numbers. Already opened gates at the RAM you can read faster from than if you must open a new one at a random spot. Trivially hashtables you have not opened it at that random spot yet. That is an additional latency extra that addes to this 130. Most likely that will add up to like above 280 ns up to 400 ns for dual Xeons DDR ram 133Mhz. Best regards, Vincent
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.