Author: Vincent Diepeveen
Date: 16:22:32 02/15/06
Go up one level in this thread
On February 15, 2006 at 07:45:37, David B Weller wrote: >I am a broken man ... My experience is that just asking questions usually works, as you'll check all those details out and fix bugs there. So below a number of questions... >I have been searching in vain for the reason(s) that my engine searches so >slowly compared to others... > >1/5 the NPS what nps do you get at which hardware? >5 ply less >NPS and depth is still < Gerbil even when using a rediculously simple SE of >material ONLY >using: >AlphaBeta fail soft with Aspiration=30 and PVS Aspiration oh dear. Throw it away. You get a reliable score from hashtable anyway within a node or 200 which annihilates the need for an aspiration window. >Null Move R=2 (no verification) use R=3 and double nullmove. Gives another extra ply for free... Verification search was invented by Omid when he still was busy starting computerchess. Very bad idea to use. >Futility Pruning at Frontier >Delta Pruning in Quies Hello, i've been missing some stupidity here as of lately probably. Any type of pruning in qsearch is pretty silly to do. First of all first count what you could possibly save out. In diep i could save out a potential 3% of nodes at most by doing some type of futility in qsearch. Should one take huge risks of crippling my entire program as a result of futility in qsearch in order to save out another 3% of nodes? >Low History Reduction [late in move list] >*not using IID. It does not help >Extensions: >Check >One Reply >Mate threat >Pawn to 7th > >extension are UNLIMITED >[tried several extension limiting schemes with little difference] > >Move order: >ETC [used only when in check] Actually this is a pretty good idea. i'll check it out. >HASH >PV pv?? don't you have a probe or 4 from hashtable already. >MATE KILLER >MVV/LVA >KILLERS (2) >HISTORY >Static eval is about half way between Gerbil and Crafty [in complexity] in general fixing stability bugs in eval usually searches another ply deeper. >I have profiled the code, and there is nothing abnormal. Spends most time in >eval. [IIRC 30+ %] sounds like a lot to me for such a small eval. >Estimated average branching factor is 2.4 [tested on positional suite] >*maybe higher in games >please help. About to go 'stark raving mad' But you forgot to mention the most important thing. What language are you programming in? I remember i helped out an Australian programmer one day and just pointed him to profile his c++ code. Not long after that his engine speeded up 2 times in nps. Now let's not discuss silly programming languages like JAVA nor C#. Perhaps good for GUI's but writing an engine in it is really asking for trouble and a slowdown of factor 3 to 5. Secondly how much testcode did you write in order to test that what your program is doing is also working? Usually i start an amateur program. I see it spit out big nonsense from hashtable and i ask the author to remove some bugs from his hashtable. What proof do you have that your hashtable is working bugfree. Did you test 100% correct your hashkey? Like test after every makemove and unmakemove that the hashkey was correct? How many probes do you do and do you clean your hashtable *before* you give a newgame? What overwrite strategy do you use? And so on. Please remember, in 1997 it was quite common to search 10 ply and to die around 11 ply with a branching factor of 10.0 Secondly extensions. Just throw out extensions. Extend at most getting out of check. Throw out the rest. Are you 100% sure that you don't search further after making an illegal move, is it garantueed you capture the king as first? Vincent
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.