Author: Vincent Diepeveen
Date: 09:07:36 06/26/01
Go up one level in this thread
On June 26, 2001 at 10:32:07, Pham Minh Tri wrote: >On June 26, 2001 at 09:16:54, Vincent Diepeveen wrote: > >>On June 26, 2001 at 01:20:16, Pham Minh Tri wrote: >> >>>My program has not attack tables yet. It is based on mailbox structure. I am >>>considering to implement them. I wonder how fast of a mailbox+attack tables is, >>>compared with bitboard (in percent). Does anyone have experience or make a >>>comparison? >>>Many thanks, >>>Pham >> >>I can generete non-incremental around a million attacktables a second >>or so. I'm only using something extended upon what gnuchess 4.0 >>is doing. >> >>Note that incremental it's not much faster, but you don't need to >>check all kind of things anymore like whether someone is in check, >>so right now i'm doing things incremental, though in the past it >>was faster for me to not do this, because if i get a transposition >>cutoff from transtable in qsearch somewhere, then of course i didn't >>need to update anything as the probe was first! >> >>Of course attacktables work cool and of course you need at least >>2 types of info: >> a) what kind of pieces attack you, just piece number 0..31 is a bit >> too primitive. >> The ctlN,ctlR,ctlQ from gnu 4.0 is way better >> b) how many pieces attack a square is very crucial information, >> humans always take that into account for example! >> >>Of course if you're used to get hundreds of nps a second, then >>using attacktables in evaluation suddenly slows you down considerably. >> > >Yes, I have just built my first attacktables without increment and I lost >1/5-1/4 of speed. They burnt all my effort of 6 months to re-write my program to >be more efficent :-( > >>Using attacktables in evaluation is a clear choice that says: "chessknowledge >>is more important as other things". >> >>Note that the good thing if you have good attacktables is that you can >>more easily order moves everywhere and be more efficient as you have >>more info to decide whether you try a move or not, >>and get rid of the dubious futility pruning in qsearch. >> >>So for the loss of speed you get back a more efficient search besides >>a better eval (that last of course still is hard work)! > >But I guess attacktables do not help move order much, so instead of them, May i beg your pardon? >someone could implement something similar (but simpler) for eval only. Did you >consider this way? No i never considered removing knowledge from my evaluation. Would only hurt my prog too. The fairy tales that knowledge isn't working are old and refuted nowadays. The only progress in Tiger is obviously a bit of knowledge, whether that's preprocessor or not, that's not interesting. Knowledge is the reason he progresses. Fritz is the only one i can't say from clearly it has increased in knowledge bigtime, but it obviously *has* improved there to some extend. For Shredder the promotional reason nowadays is that it has a lot of knowledge. Definitely Stefan has worked on endgame knowledge, that's where all his world titles in combination with good testing, are based upon. So it's nowadays even a sales item. Of course speeding up a progrma lossless is different. I have tried that a thousand of times. I guess my move generator has been rewritten thousands of times, then dissasssemble it, measure how many clocks everything eats and measure speed of it and usually get amazed that processor is a bit different as i thought. Then again rewrite it and so forth. Scanning the board fast is important for DIEP. Because i scan a lot in evaluation. Taking away those scans would definitely make the biggest speedup. Evaluating patterns is relatively cheap, because with a few 'if then else' you can disable thousands of patterns easily, where slow scans of parts of the board are always hurting bigtime. >>A trick is to speedup the evaluation is to store it >>in a special hashtable. that's just >>200 clocks or so to retrieve. Compare that with a 100000 clocks which >>an evaluation is costing here. >> >>I get with several hashtables (i store in transtable and special eval >>table my evaluation) about 60% of all my evals out of tables. > >I do not know how your hashtable of eval table diffirent from normal ones, but I >tried to use (normal) hashtables in qsearch, they did not help much (speed and >score). I guess your eval should be very heavy (and slow), so they can work. Definitely there is a price for transposition tables. Note i use 8 probes (sequential). Perhaps that's helping me. I am pretty sure it's hard for me to improve hashtables. Perhaps a new chip gives new thoughts on that. Slowly it seems that the size of cache lines of memory get bigger and bigger. So perhaps soon loads of people do more as 2 probes... >Thank you for sharing knowledge and experience. >Pham You're welcome. >> >>Best regards, >>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.