Computer Chess Club Archives




Subject: Re: Detecting Draws using a Small Hash Table?

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
>>>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.
>>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
>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.


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.