Gian-Carlo Pascutto wrote:
A few that stood out to me:
1) Separate search functions for, well, everything
I blame Fruit for the basic idea, but Rybka takes it way further.
2) Calculating both opening and endgame scores simultaneously by packing them both into an integer, thus saving ADD's.
3) Calculating move ordering scores at the same time as generating the moves.
I answer for each point:
1) The only further "separation" that there is more then in SF is white/black splitting. I have tested not the search, but the do_move(), to split in do_move_white() and do_move_black(), with almost no difference.
Well in SF we use templates to do this so that there is no source code redundancy. Sometime it helped, as example in evaluation, to split in white and black, so for instance we have:
Code: Select all
evaluate_king<WHITE>(pos, ei);
evaluate_king<BLACK>(pos, ei);
Instead of a color loop, this helps becasue many indirect memory access are resolved at compile time and become direct ones. But in do_move() and in search() it doesn't help at least for SF.
Actually templetized version of do_move() is still under testing, but even if it helps we are below 1%.
2) This is what I call an ugly trick because is not platform independent (32/64 bit). And also if you save an add you also earn a left shift
The only advantage is to pack always in a uint32_t instead of a 2 unint32_t for 32 bit CPU or 2 uint64_t for 64 bit machine, but usually avoiding the natural 'integer' of the CPU is never a suggested technique and gains are all to be demonstrated.
3) This is horribly ugly becasue compeltely breaks the nice separation between move generation, scoring and sorting. And BTW I am not sure you save anything becasue you need an extra access during capture's move generation to a big table of precalculated MVV/LVA scores and also an extra access to look up what kind of piece you have in destination square. So the only save you have is the piece lookup of the origin square that during move generation is already known (of course) while if you score later you have to do it, but the origin square piece lookup is very fast because board[] is only 64 squares and is always in L1 for the whole scoring. So I think it is ugly and with very little gain (if any).