Author: James Robertson
Date: 20:02:18 05/04/99
Go up one level in this thread
On May 04, 1999 at 22:05:04, Will Singleton wrote: >On May 04, 1999 at 20:41:48, James Robertson wrote: > >>On May 04, 1999 at 18:32:29, Will Singleton wrote: >> >>> >>>On May 04, 1999 at 15:28:19, James Robertson wrote: >>> >>>>On May 04, 1999 at 15:03:08, Will Singleton wrote: >>>> >>>>> >>>>>On May 04, 1999 at 13:07:42, KarinsDad wrote: >>>>> >>>>>>On May 04, 1999 at 12:40:05, Andrew Williams wrote: >>>>>> >>>>>>>On May 04, 1999 at 11:26:29, KarinsDad wrote: >>>>>>> >>>>>>>>I was wondering how deeply most programs extended the search at a given ply for >>>>>>>>check. >>>>>>>> >>>>>>>>I implemented singular extensions, check extensions, and capture extensions into >>>>>>>>my code last night, but ran into the problem of check extensions potentially >>>>>>>>expanding the extensions into near infinity. >>>>>>>> >>>>>>>>How many checks do most programs consider is enough when extending? >>>>>>>> >>>>>>>>Thanks, >>>>>>>> >>>>>>>>KarinsDad :) >>>>>>> >>>>>>>My program simply says "if the iterative deepener started this search >>>>>>>with depth=D, don't extend beyond 2*D". This is a naive approach, and >>>>>>>I'd also be interested in hearing what anyone else does. >>>>>> >>>>> >>>>>Sometimes the simple approach is the best. In mine (which I'm sure is not the >>>>>best), I simply limit total extensions to 6 beyond depth. But I also consider >>>>>some checks in the qsearch. >>>>> >>>>> >>>>>>Yes, this sounds naive since I especially do not want to check 14 ply down when >>>>>>I am currently searching Ply 14. I was thinking more along the lines of 8 ply >>>>>>(if you do not get an advantage within 4 moves, then maybe it isn't worth >>>>>>checking), but I am not sure. >>>>>>> >>>>>>>> >>>>>>>>PS. Will, we realized that our nps is way off. We were compiling the code in >>>>>>>>debug mode as opposed to optimized mode. So, our 100 knps went up to 209 knps. >>>>>>>>Duh! >>>>>>> >>>>>>>209knps!! What position? >>>>>> >>>>>>This is on a P3 400 Mhz with super simple material evaluation code (for a lot of >>>>>>positions, the program is still real stupid). It will drop in half at least once >>>>>>I really implement the evaluation. >>>>>> >>>>>>> >>>>>>>Andrew >>>>> >>>>>The most nps I get is around 90k, in the endgame. Avg around 60k on a mac 300. >>>>>Even with a material only eval, I don't approach your numbers. You must be >>>>>doing something right! >>>>> >>>>>btw, it's possible that you'll see reduced node counts due to increased cutoffs >>>>>when you add some positional stuff. >>>>> >>>>>Will >>>> >>>>On my P233 I get about 120k NPS in most middlegame positions. In the endgame, I >>>>get 200-270k NPS. With material only, I got greater than 300k. >>>> >>>>James >>> >>>What search method do you use? And is it bitboard-based? >> >>Standard Alpha-Beta. And yes, I use bitboards, and a ton of assembly in my basic >>movegenerating, etc. >> >>James > >Assembly and bitboards, huh? Bitboards I understand, but assembly? I always >found it tough to modify, pretty intense. This was 80x86 and 68000 stuff. > >Compilers are pretty good these days, how much do you think you gain? > >Will From my original C++, at least 2x. I could probably write better C++ now, but I am too lazy to see how it compares to my assembly. James
This page took 0.01 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.