Author: Vincent Diepeveen
Date: 07:13:07 04/15/03
Go up one level in this thread
On April 14, 2003 at 04:47:44, Andreas Rueckert wrote: >Hi! > >I'm thinking about a incremental movegenerator for our little project. The idea >is to store the moves for the pieces in a array and then check the last moved >pieces, if they intersect with the potential moves of the piece on the square. >If not, the moves that were computed before the piece was moved, could be >reused. Has this been done before? (I guess so, since almost everything has been >tried in this field, as it seems to me). Are there any numbers, how much >performance gain is too expect from such a solution? for a beancounter that is psq only i assume is your question as in diep move generation including generating all moves at every qsearch node is < 0.6% system time. it is trivial that incremental generation is fastest. you just pick 1 piece and generate all moves for it. if first move generates cutoff then you had a cheap cutoff. Yet search efficiency is poor of course as perhaps some other move was better to try first. Let's skip that. We all know fritz 5 and older than that must have used incremental move generators. Perhaps you can get to 10 million nps speed at a fast K7 with incremental move generator (of course pseudo legal, not legal). Best regards, Vincent > >TIA, >Andreas
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.