Author: Vincent Diepeveen
Date: 09:54:25 03/01/01
Go up one level in this thread
On February 28, 2001 at 12:17:48, TEERAPONG TOVIRAT wrote: > >>You will run this to test to speed of your movegen and makemove? >>That's how I understood your original message. > >Actually,my current program is checkers one. In former version, >I use single array board representation. After I read Amy source >code,I understand how bitboard works. I heard many people said >bitboard can generate move faster in chess. In checkers, >some facts are no nullmove,no killers,no PVS ,no SEE etc..and No pvs?? For me PVS works best in draughts, quite similar to checkers when talking about search approach. No nullmove of course. Killers work a bit but not so well. SEE is not there as capturing the longest string is forced in draughts (not in checkers there you can chose). >very simple eval() and plain AB function with hash table. also very simple eval in my Napoleon, i think about 3000 lines of C source code at most. >So,I think if I can improve movegen() speed,my program >will be stronger. Then, the project start ,I wrote a new checkers >program based on bitboard ,modified from Amy. The result was >quite dissapointed it's slower. You may look at what Dr.Hyatt >commented. Amy bitboard always updates attack_to,attack_fr >informations in (un)makemove()s. If only 2 movegen()s were >compared, bitboard is slightly faster. But if test it in combination >with (un)makemove()s,it becomes slower in proportion to the >ratio of (un)makemove()s. So,this is my original question what >is the optimum ratio between them. >Is it acceptable to use branching factor ? >How other people test these problems? >I don't know really. I'm not a great programmer :) >Now,I focus of movegen() in Crafty. I plan to modify it into my >program. I still have some hope with bitboard. I wonder how you plan to use bitboards in a checkers prog. Despite that it's just 32 squares in total you need, you can't shift things to the next row simply. One would need a bigger bitboard for that. Way faster is the sequential way of doing things. In assembly you could use some PII instructions even removing all problems. However the only problem my draughtsprogram has is not the generation speed. not even evaluation speed. the problem is the transposition table speed. It's already that hell fast that only hashtable lookups and writes hurt... ...not to mention egtb lookups... >>I don't understand what you mean when you say this: > >>"And call it recursively to count number of visiting nodes then compare >>with our real search()." >I remember when I experimented about branching factor myself. >I have some problems ie.it varies from ply to ply ,from position to position >and from game to game. Please remember we didn't talk how the figure >4 are from. Perhaps,the branching factor is 4 in some situations and >less(more) than 4 in some situations. So,a perfect test,IMHO, should >have approximately the same nodes as normal search() does. >Perhaps,I'm too anxious about this. You may call me a Mr.perfectionist. > > >>Count which nodes? Isn't it obvious how many you will visit? >>What will you use that number for? Am I still missing something? > >Just to convince you that your figure is too high. > >I think now we have reached some agreement. >I'm really happy for your interest to my post. I cannot find >anyone surrounding me who interested in computer chess, >so, I think CCC is a wonderful place. CCC lets me express my idea >and gives me some interesting ideas from other people. >Now,it's late at night again... :) > >Teerapong
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.