Computer Chess Club Archives




Subject: Re: Source code to measure it - results

Author: Robert Hyatt

Date: 14:58:21 07/17/03

Go up one level in this thread

On July 17, 2003 at 03:43:57, Tony Werten wrote:

>On July 16, 2003 at 12:08:58, Robert Hyatt wrote:
>>On July 16, 2003 at 01:39:34, Andrew Dados wrote:
>>>On July 15, 2003 at 21:13:23, Jeremiah Penery wrote:
>>>>On July 15, 2003 at 20:19:34, Vincent Diepeveen wrote:
>>>>>On July 15, 2003 at 15:24:19, Gerd Isenberg wrote:
>>>>>Gerd use it with a bigger hashtable. Not such a small
>>>>>400MB is really the minimum to measure.
>>>>Measuring 90MB, something like 99.65% of the accesses should be to RAM and not
>>>>cache.  With 100MB, it's 99.8%.  Yet when I measure those two things, I get a
>>>>whole 6.1ns latency difference according to your test.  Even measuring only
>>>>20MB, 98.4% of the allocated memory can not be in cache. (All of this assumes
>>>>that the program takes up 100% of the cache, which it won't.)
>>>>There's something wrong that causes memory access time to be reported much
>>>>higher when testing larger 'hashtable' sizes.  Anything large enough to
>>>>overwhelm the cache should report similar, if not almost identical, results.
>>>>However, your program gives wildly different numbers.
>>>>Trying to allocate 12500000 entries. In total 100000000 bytes
>>>>  Average measured read read time at 1 processes = 183.935982 ns
>>>>Trying to allocate 11250000 entries. In total 90000000 bytes
>>>>  Average measured read read time at 1 processes = 177.806427 ns
>>>>Trying to allocate 43750000 entries. In total 350000000 bytes
>>>>  Average measured read read time at 1 processes = 253.592331 ns
>>>>In the last test, I can't be completely sure I wasn't paging at all.  I didn't
>>>>see the disk light flashing, but it's possible that this hit the disk more than
>>>>once, which would make the number look much higher than it should.
>>>>Still, relative to the other results people have given, this is not so bad,
>>>>since I have only PC2100 memory (133MHz DDR).
>>>Get rid of RNG.. do lookups every x+32 bytes (or so), after exhausting hashtable
>>That will fail on a PIV.  It's L2 cache line is 128 bytes.  You will see 1/4
>>the real latency, roughly, because 3 of every four probes will be a cache
>I don't see the problem.

I was responding to the "lookup at every X+32 bytes.  X=32 is fine for
everything before the PIV.  But the PIV went to 128 byte lines in the L2
and that would skew latency numbers.

>Create an array of pointers (100.000.000 should do), start with entry[0],
>generate a good random number (ie minimum distance from last one etc), let
>entry[0] point to the new entry, now get a new random number, ect till end.
>It doesn't matter how long this takes.
>Now start measuring how long it takes to run over the table starting from entry
>zero. This should be a clean measurement of memory speed, hardly any overhead

This page took 0.02 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.