Home * Engines * EXchess

EXchess, (Experimental Chess Program)
a Chess Engine Communication Protocol compatible experimental open source chess engine released under the GNU Public License, written by Daniel Homan in C++, optionally using an own GUI based on the Fast Light Tool Kit (FLTK).

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

EXchess uses 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].

TD-leaf

EXchess applies evaluation learning using the Temporal Difference Learning (TD-leaf) [4].

Lazy SMP

Daniel Homan in July 2013 on his Lazy SMP implementation and work sharing [5]:
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 [6]. 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.


Forum Posts

1998 ...

2000 ...

2005 ...

2010 ...

2012
2013
2014

2015 ...

2016
2017

External Links


References

  1. ^ EXchess v5.01 beta source code, chess.h, moves.cpp
  2. ^ SEE and possible EXChess bug by Gian-Carlo Pascutto, CCC, April 01, 2001
  3. ^ EXchess v4.02 released by Dan Homan, CCC, April 10, 2001
  4. ^ New version of EXchess by Dan Homan, CCC, November 18, 2000
  5. ^ Lazy SMP and Work Sharing by Daniel Homan, CCC, July 03, 2013
  6. ^ ABDADA speedup results by Daniel Shawul, CCC, May 01, 2013

What links here?


Up one Level