Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Source code to measure it - results

Author: Robert Hyatt

Date: 11:37:44 07/16/03

Go up one level in this thread


On July 16, 2003 at 13:04:40, Keith Evans wrote:

>On July 16, 2003 at 07:20:50, Vincent Diepeveen wrote:
>
>>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
>
>Let's take a simple example for starters:
>
>Say that you read from memory location 0x00000000, then 0x01000000, then
>0x02000000.
>
>Do you define this as sequential? What hardware mechanism makes the accesses at
>0x01000000 and 0x02000000 occur faster than the first access to location
>0x00000000?

None of course.  But I think you are going to find it difficult to
convince "some" of this.  :)




This page took 0.04 seconds to execute

Last modified: Thu, 07 Jul 11 08:48:38 -0700

Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.