copy/make vs make/unmake

[Aaron Becker]

Weird coincidence, I've been slowly revamping my engine and ran a similar do/undo vs copy experiment last week. My result was similar--about a 5% advantage to explicit undo (with a somewhat smaller board state to copy).

[Evert]

Guess it depends on the program.

One of the previous times the discussion came up I converted Jazz from copy/make to make/unmake and there was hardly any difference in speed or strength. I forgot the details but I think the make/unmake was actually slightly slower.

There are always some things that need to be stored because you can't reconstruct it using unmake though and it's possible that the way I did this was a bit clumsy. Jazz' board struct is only 96 bytes though, making it larger does hurt and slow things down.

[lucasart]

I use a hybrid approach in DiscoCheck:
* some things take much space but are easy to recalculate on undo(). these can be recalculated, in the hope that the lesser cache pressure will make up for it.
* some things don't take much space but are costly to recalc: those belong on an undo stack.

I started with a plain and simply make/unmake, where I was recalculating everything from scratch. Then I introduced the undo stack as an optimization, and started profiling and fine tuning until my raw perft reached ridiculously speeds... Eventually I realized that none of this matters in a fully fledged engine.

Actually, the first thing that comes up on my profiling is the search(). And by a decent margin. It is not the eval, and certainly not the make/unmake stuff.

I don't think we can answer the question of make/unmake vs make/copy in general. Every engine is different.

[tpetzke]

Code: Select all

Actually, the first thing that comes up on my profiling is the search(). And by a decent margin. It is not the eval, and certainly not the make/unmake stuff. 

This surprise me a bit. What is search doing beyond few comparisons and then calling itself ?

Last time I profiled iCE the single most expensive function was calculateMobility<EColor> which is only a subfunction of eval().

But I agee to see makeMove and unMakeMove I must scroll down a bit.

[Daniel Shawul]

I don't think we can answer the question of make/unmake vs make/copy in general. Every engine is different.

Exactly, "Piece-list engines" like mine would prefere make/unmake or a combo by a huge margin. However I used copy/make for an engine I wrote for the GPU using bitboards.

This is yet another optimization that an eninge author should figure by himself.

[mar]

Actually, the first thing that comes up on my profiling is the search(). And by a decent margin. It is not the eval, and certainly not the make/unmake stuff.

I get the same impression, last time I profiled eval was only 25% of total in my case, vast majority spent in search.