Author: Geoff
Date: 02:42:04 05/03/03
Go up one level in this thread
Hi Ross
Thanks for this excellent reply it was just what I was looking for !!
>TSCP is a good place to start.
Yep agreed, it was the only one I could vaguely understand at the start :-)
>Maybe calculate mobility in your move generator? It won't be accurate though >you generate pseudo-legal moves only.
Not quite sure how this could be done, as the move has to be made first before
calculating mobility for both sides.
>I found killers to be effective but it depends a lot on your move ordering.
>I don't allow captures in my killer slots. And my killers get ordered between
>winning captures (eg PxQ PxR) and losing or equal captures (eg QxP QxQ).
>
>So, in the move ordering I try
>
>1. PV move
>2. bestmove from hash table
>3. Winning Captures (PxQ,PxN etc) in mvv/lva order
>4. Killer 1,2,3 (remember these are never captures)
>5. Losing/equal captures (QxP QxQ etc) in mvv/lva order
>6. All other non-captures are ordered by history scores
>
>Its probably not optimal but its better than nothing.
That is interesting, I think I need to concentrate on this area. I have tested
my killer move mod, I took out the PV and the history sorting and retested the 2
killer moves only ordering. For the start position it reduced the nodes searched
to 93% of that with no move ordering. That was enough to make me think my code
was working as I meant it, but a small enough improvement to make me think I
have not understood something properly ?
>I'm a beginner too and I was amazed how easy it is to implement nullmove.
>Just remember to clear the ep square and then restore it immediately after the
>null search. With TSCP I had to modify the makemove and takeback functions.
>Some debugging may be required but its really worth the trouble. Huge speedups.
Null moving makes my brain hurt, think I will leave this one till I get a bit
more experienced in chess programming !!
>1. In TSCP you can write a dedicated root_search() function to handle ply 1.
>Then you can resort the root moves based on their actual scores after each
>iteration. This worked well for me.
Sorry, I don't think I follow what you meant by this mod.
>2. If you are using TSCP's attack() function, rewrite it. Instead of looking for
>pieces which attack a certain square, work outward from the square and look for
>a potential attacker. Its heaps faster.
Oh yes thats a good idea, for some reason it hadn't occured to me yet. It
probably would have done eventually. lol
>
>3. TSCP also benefits from keeping track of the two king's squares. The
>in_check() function scans the whole board looking for the relevant king's square
>before calling the attack()function. I created two global variables wksq and
>bksq and update them in makemove() and takeback() whenever the kings move.
Yes, I have already done this same mod, I just forgot to mention it, agreed it
did give a marked improvement
>4. TSCP can benefit from using piece lists so it doesn't have to loop 64 times
>in gen(), gen_caps() and eval(). It means makemove() and takeback() become a
>little messy but its a good speedup.
Thats another one I hadn't thought of yet !
>5. Converting TSCP to an 0x88 board representation is also worthwhile.
I recall seeing a write up of this somewhere, the TSCP 'mailbox' move gen code
looked quite efficient so I thought it wouldn't really benefit from an 0x88
system.
>That should keep you busy for a while... :-)
Yes, that is very true !!!
>Just adding hashtables and nullmove to TSCP (plus the above tweaks) will make
>TSCP search its built-in benchmark to 6 ply at least 25x faster.
Strewth, that is an amazing figure, what would you guess the individual speedups
were for each of those mods ?
Thanks again Ross, lots of food for thought there !
regards Geoff
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.