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 >>>>>table. >>>>> >>>>>400MB is really the minimum to measure. >>>> >>>>Why? >>>> >>>>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 >>>inc(x) >>>-Andrew- >> >>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 >>hit. > >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 >etc. > >Tony
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.