Board Representation

EXchess utilizes an 8x8 Board and piece lists as demonstrated in its move generation routine ^[1] :

struct square {
  char type;             // type of piece (0 - 6)
  char side;             // side which owns square (1 = white)
};

struct position {
   square sq[64];
   ...
   char plist[2][7][10];
   ...
};

void position::allmoves(move_list *list, tree_search *ts) {
   ...
   for(i=1;i<=plist[wtm][PAWN][0];i++)
     pawn_moves(list, plist[wtm][PAWN][i], ts);
   for(i=1;i<=plist[wtm][KNIGHT][0];i++)
     knight_moves(list, plist[wtm][KNIGHT][i], ts);
   ...
}

Search

The ches engine performs advanced search algorithms including principle variation search, null move, null move verification, dynamic search extensions, futility pruning, hash tables, history tables, quiescence search, and a material swap function ^[2] ^[3].

Lazy SMP

Daniel Homan in July 2013 on his Lazy SMP implementation and work sharing ^[4]:

I changed the work-sharing approach to Lazy SMP in EXchess to be closer to the ABDADA model after Daniel Shawul's posts about his tests on the subject ^[5]. However, I didn't want to use a hash table to keep a counter for the threads working on a given position. My hash table already had a 16 byte long entry, so I didn't want to expand it, and I also didn't like the idea of having to make each move before seeing whether another thread was searching it.

So as an alternative to the hash table, I made a simple work sharing data structure. In the end, it was just a single hash key for a position which is OR'd with the move being searched and the depth of the search. I use this to keep track of the move being searched at each ply of the tree for a given thread. Then, before I search a move at a given ply, I can just check the same ply in the other threads to see that the move is not already being worked on at that depth. If it is, then the move get placed at the end of the move list to be searched last. This doesn't allow for transpositions , but I expected the most likely work collisions to be as the threads are walking the PV where they will initially all be the same. Indeed, this scheme only helps in the PV, and if I check for work sharing in non-PV nodes, it only slows things down a bit.

My previous Lazy SMP work sharing was just to alternate moves (odd-even) in the root node for the odd-even threads. The above approach is about 10% faster than my previous scheme, and I get a time-to-depth improvement of roughly 1.65 for 2 threads compared to 1 thread and roughly 2.5 for 4 threads compared to 1 thread. Maybe not quite as good as ABDADA with a hash table counter, but not too bad for the simplicity.