Computer Chess Club Archives




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

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
>>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?
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 ;)



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.