> - Improve the speed of position searching > Scid use only 1-byte for non-queen moves, and it's very > clever, but very slow to decode. > Nowadays harddisk space is not a problem and a 2-byte for > move format will be more appropriate in my opinion.
Steve is right that file IO is the slowest part. I did an experimental two byte move decoding, and a test with database Big2010.sci (converted from Big2010.cbh) which contains 4.462.803 games. After I did the move 1.e4 the position search (in opening tree window) took about 20 seconds. The one byte version needs only about 10 seconds. The result: a two byte decoding is slowing down the position search by factor 2. > Scid use only 1-byte for non-queen moves, and it's very clever, > but very slow to decode. This is not true, the decoding is fast, although the two byte decoding is faster. (By the way, the ChessBase decoding is slow). > scid use a very clever tree_search algorithm that read on average > less than 5% of the sg4 database. Yes, this is true, but this means that a faster decoding cannot have a significant impact. But the disk IO has a very significant impact. Furthermore on average only a few moves will be decoded in a game, the tree search algorithm is indeed clever. Gregor
