Author: Thomas Mayer
Date: 15:37:36 02/19/04
Go up one level in this thread
Hi Uri, > It seems faster than what I thought to do and the only question is if it is > faster than what I have. you will never know without trying it out. Believe me, I did try a LOT of things which were senseless later. At the moment I have two 32 bit variables for the hashkey -> seems to be faster for me then one 64 bit... for whatever reason. Also I have very complicate incremental stuff for some pawnstructures. Nowadays I am quite unsure if it really pays off. Once I did try to transfer the pawnstructure to Bitboard... well, it was working, but dead slow. Anyway I might give it another try in the future. You know I have some new ideas. Also I have incremental pawn-attacktables. Nowadays I am also unsure if this the stone of wisdom. Still I think Quark has some lack of speed and I work permanently to increase it. There are two fields to speed up: a) increasing the speed of the code b) shrinking the tree... Both help a lot and b) is not measureable in nps. E.g. for the future I plan incremental attacktables and maybe also incremental moves. (So no move generator anymore at all - it will have the moves always handy because it updates them incremental) If this is worth something I have no idea -> and I will never know as long I do not try it out... E.g. when I understood Eds pages correctly his attacktables for move ordering speeds him up about a factor of 3.2 when comparing nodes to depth. So who cares when you lose 50% nps... You will anyway have a nice speed up. So I will try it. If it does not work - well, back to the old source, usually on the fly I find many other bugs... :) Greets, Thomas
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.