Author: Uri Blass
Date: 06:46:05 02/21/02
Go up one level in this thread
On February 21, 2002 at 08:49:58, Sune Fischer wrote: >On February 21, 2002 at 08:10:50, Uri Blass wrote: > >>>>O(50) is not so big and it is not going to happen in every node in the >>>>search(even in that case I believe that the difference in speed is not more than >>>>10%). >>> >>>Your 10% seems like a wild guess, why not 50%? Do you have 500 conditionals in >>>your eval or something? >> >>I admit that 10% was a wild guess but even twice slower in these rare cases when >>in most cases it is less than 10% slower is not going to get your program more >>than 10 elo weaker. >> >>I do not 500 conditionals in the evaluation. >>My evaluation is only piece square table and the main problem is my move >>generator. >> >>I generate only slightly more than 150,000 nodes per second in the opening >>positions on p800 because my move generator generates information that is not >>used today(attack tables) >> >>It may be 200000-300000 nodes in the endgame. >> >>I do not know what is the situation of your program but I guess that it is not >>clearly faster(otherwise I could expect better results than the results that it >>did in a tournament of new engines in the winboard forum and I am happy that my >>stupid program that only has piece square table evaluation and is pronbably only >>slightly better than tscp based on my tests got the 3th place out of 10). > >Hehe you got me there;) >I didn't even know it had been tested - oh horror. >Well my next version will be completely different, still too buggy to release >but it's woppin' the old one (when it's not crashing:). > >I think 150 nps is a little low if you don't even have complicated evaluation, >I'm running at 500 nps in middelgame (athlon 1 gig) with piece-square, mobility >plus some simple pawn and kingsafty eval and close to 1Mnps in endgame. I know >there are some spots that can be tuned, but speed is not my concern, it is the >search algo I must improve. I am still doing a full-width alpha-beta without >nullmove. I want to fix the simpler bugs before enhancing that part :) I also do a full width alpha beta without null move today so it is not the advantage of my program relative to your program. Maybe my advantage is the extensions but I extend only in cases that the king is in check and in cases that there is only one legal move. Maybe my advabtage is better qsearch or better order of moves but my order of moves is similiar to tscp and I use only history table. > >>My opinion is that almost all the new engines including mine are very weak and >>you have more important things to worry about than a faster repetition >>detection. > >You are right, but I just joined the discussion :) > >BTW: are you using a UnMakeMove function or do you use a backup? >I do a backup, seems both faster and simpler than to unmake the move, I'm a >little confused as to why some would unmake. > > >-S. I do unmakemove I guess that I can make my program slightly faster by rememebering the changes that I do in makemove and unmaking them. I thought about this idea but I decided to stop to work on my move generator after it helped me to be faster than everything that I know in calculating perft. Uri
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.