Author: Johan de Koning
Date: 00:48:31 09/04/03
Go up one level in this thread
On September 03, 2003 at 14:53:23, Robert Hyatt wrote:
>I finally found time to run a few tests.
>
>First, the set-up: I took all my bitmap stuff, added it up, and put it in
>a structure that was then set up as an array. IE tdata[128] was an array
>of these structures, each element being just enough bytes to hold all of what
>I call a "position" including bitmap boards, hash signature, 50 move counter,
>etc...)
>
>At the top of MakeMove() I added tdata[ply+1]=tdata[ply]; to do the copy
>stuff. That's all.
>
>Some results:
>
>fine 70 searched to 39 plies deep:
>
>copy/make : 15.5 seconds, make/unmake 14.0 seconds (11% overhead)
>
>kopec 22 searched to 12 plies deep:
>
>copy/make : 32.4 seconds, make/unmake 28.3 seconds. (14.5% overhead)
>
>mate position searched 9 plies deep (mate in 10)
>
>copy/make : 8.9 seconds, make/unmake 7.5 seconds. (18.7% overhead)
Thanks for finding the time.
I do however have some suggestions to create even more valuable data.
(Would you have expected anything else? :-)
(a) Name hardware!
Preferrably also name system, software, compiler.
(b) List the exact positions.
Include some normalish positions.
List N/s.
To avoid the suspicion that fast eval and lazy eval cause these particular
positions to have a particularly high N/s (hence high copy cost).
(c) Make the copying dependent on a global flag.
Eg: int DoCopyIf12 = 13, to make sure the memory layout is exactly the same
for both runs.
(d) Run several times.
Just to get an impression of the variance in the timing.
(e) Check the code (or list it).
To make sure the compiler doesn't do anything stupid (it happens).
>That's not all the story. however. The copy/make approach requires an
>extra register everywhere since the data structures have to be accessed
>through a pointer (or via an array subscript, same thing). My test case
>does not take care of that. But if you were to mark one register as
>"unusable" for the compiler, the result would be worse, for certain. Since
>these data values are accessed all over the place, a register has to be used
>everywhere, which is going to add to the above, significantly.
Indeed, "all the story" is always YMMV.
On a RISCish machine registers are cheap while absolute adressing is expensive.
Hence addressing data through struct pointers is usually faster. On the 386
registers are bloody frikking expensive. But pointers (in general) save you a
lot of code space. :-)
> If it only adds
>10% then the above numbers are back to what I originally saw when I speeded
>things up by 25% by getting rid of copy/make.
A fictional 10% won't suffice to even the balance, since you added prepare_undo
to make() and unmake() to search(). A fictional 20% would probably do the job,
but I won't buy that.
... Johan
>That's data for Crafty. YMMV of course...
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.