Author: Matthias Gemuh
Date: 00:47:55 12/06/03
Go up one level in this thread
On December 05, 2003 at 18:49:37, Matthew McKnight wrote: >On December 05, 2003 at 18:31:34, Matthias Gemuh wrote: > >> >> >> >>The ratio nullmove_cutoffs / main_search_moves_searched is only 15%...20% >>in my program. Is this extremely low ? >>My BigLion searches at miserable 180 kN/s on 2.6GHz. >> >>/Matthias. > >I count nullmove_cutoffs/null_move_tries, and I think I get around 65%. I'd >guess that 15-20% with your calculation is comparable, if not better than mine. > Calculated that way, I also get about 65%. This can be raised to even 80% if you evaluate each internal node. >180 kN/s is not bad if you are doing a lot of work in eval, or other things that >slow you down, as long as you are compensated. With BigLion's performance, I'd >say you are succeeding here. BigLion indeed has a heavy eval (as eval.prm suggests), but even with only piece square tables, BigLion remains slower than 250 kN/s. Maybe I shall one day find a speed bug. >I have driven myself crazy trying to increase nps, >but I find that simple improvements to search and eval seem to increase my ELO >the most. I don't think Dorky 4.0 still needs improvements ;). Here is an example: if your program runs a factor of x slower than >crafty on the same hardware, then find some hardware that is x slower than >yours. Run Crafty or Ruffian on the slow machine, and see if BigLion can win at >approx. the same nps... This should be possible under Fritz8 GUI on one computer. I shall try it. /Matthias.
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.