Author: Sune Fischer
Date: 07:36:05 02/21/02
Go up one level in this thread
On February 21, 2002 at 09:46:05, Uri Blass wrote: >>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. I do not extend other than qsearch and I do not moveorder(!). Hehe, please no lectures, all in good time Sir. Ever wanted to know what it looks like with no moveordering? Well I can certainly tell you: Cutoff at move 1: 38936 Cutoff at move 2: 3446 Cutoff at move 3: 1017 Cutoff at move 4: 2825 Cutoff at move 5: 2771 Cutoff at move 6: 1967 Cutoff at move 7: 1257 Cutoff at move 8: 1582 Cutoff at move 9: 1064 Cutoff at move 10: 785 Cutoff at move 11: 778 Cutoff at move 12: 655 Cutoff at move 13: 552 Cutoff at move 14: 624 Cutoff at move 15: 472 Cutoff at move 16: 514 Cutoff at move 17: 757 Cutoff at move 18: 786 Cutoff at move 19: 663 Cutoff at move 20: 558 Cutoff at move 21: 483 Cutoff at move 22: 334 Cutoff at move 23: 450 Cutoff at move 24: 265 Cutoff at move 25: 505 Cutoff at move 26: 237 Cutoff at move 27: 129 Cutoff at move 28: 56 Cutoff at move 29: 53 Cutoff at move 30: 39 Cutoff at move 31: 39 Cutoff at move 32: 38 Cutoff at move 33: 44 Cutoff at move 34: 38 Cutoff at move 35: 37 Cutoff at move 36: 44 Cutoff at move 37: 38 Cutoff at move 38: 20 Cutoff at move 39: 16 No cutoffs: 13859 I guess this is not good for my branch factor...:( >>>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. What is it with you and perft ;) What is the point of being fast at perft and then slow at a real movegen? The attack tables that you generate, what kind of information is inside them that you don't have in regular attack bitboards? Are you sure that they contain such valuable information, information that can justify the speed penalty by generating them? I have bitboards, quite happey with that, I don't see what else I need. I have tried two other approaches for movegen, both of which I thought was faster than bitboards. I've come to the conclusion, that although bitboards are not _the_ fastest thing to do at movegen they do have the advantage that you can reuse all of their information a second time around in the eval(). This is the problem if you just focus at one part of your program, say the movegen as used in perft, granted you can make that really fast, but some other place will take the penalty for its speed. I think just doing what everybody else is doing can save a lot of time, hard to be innovative all the time ;) >Uri -S.
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.