Author: Tony Werten
Date: 00:43:57 07/17/03
Go up one level in this thread
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. 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.