Re: [gnugo-devel] Arend's patch

[Arend Bayer]

On Wed, 6 Mar 2002, Daniel Bump wrote:

> My testing showed that Arend's patch gives a speedup of about 4.5 %
> in the regressions. On a dual processor Celeron 433 machine, I ran
> two GNU Go processes, one with Arend's patch, and I clocked it in
> both real time and (using 'time') in CPU time.
>
> I got:
>
> (Patched)                          (Unpatched)
>
> real    569m54.019s                 real        597m11.211s
> user    462m14.510s                 user        434m39.720s
> sys     0m20.060s                   sys         0m20.190s
I thought the relevant part of the 'time' output is the user line. IIRC,
'real' just measures the time elapsed between start and end of the process,
while user shows the CPU time consumed by it. This would mean that the
patched version ran slower. Although I do not trust my timing figures for
this patch very much, I would still be quite sure that the patch should be
a speedup if the cache size is not changed. Maybe the dual processor machine
isn't suitable for exact timing measurements?

What I suggest to do with my patch is the following: It should be
best to have two compiler switches. The first should tell how many
"unsigned long"s should be used as a hash value, the second should trigger
whether the fullboard bit map is stored with each hash node.

The first could be made dependent on the system, e.g. 3 for 32-bit
and 2 for 64bit systems. Even if we change the default of the second to
turn the fullboard bit map off, we could still turn it back on for debugging.
OTOH, even if we decide to leave turned on for a while, it could be turned
off e.g. for ports to small computers.

Maybe it would not be a bad idea after all to use 96 bits for hashing instead
of 64 bits as in my patch. This would still be only a small part of the
memory needed to store a read result. Before Gunnar's comment, I had
overlooked the fact that a hash collision might trigger an assertion
failure. One completely unreproducable (without knowing the random seed)
crash report per year would already be a bit annoying, not so much for GNU
Go than for us.

I will rewrite the patch as described above unless someone else has better
suggestions. However, I will be away from tomorrow for a bit more than a
week, so it will probably take a while.

Btw, I can already promise one more patch before tomorrow, no. 1 of the
speedups I had suggested, resulting in 10% performance gain.

Arend