Author: Uri Blass
Date: 07:46:17 02/21/02
Go up one level in this thread
On February 21, 2002 at 10:36:05, Sune Fischer wrote: >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? I have for every square in the board 32 bit number that tells me the directions that the square is attacked by white and black. I also have for every direction the attacking square. I believe that this information can be used. I know that there are programs that search less nodes per second than my program(for example hiarcs) so I think that 150,000-200,000 nodes per second in the initial position is not so bad. It can be faster if I improve part of the move generaotor and it can be slower because of the evaluation function so I guess the 150000-200000 nodes per second on p800 is not going to be changed significantly. >Are you sure that they contain such valuable information, information that can >justify the speed penalty by generating them? I believe that the information can be used. >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 ;) No way I am not going to do things in the same way that other do them. I dislike this idea. 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.