Author: Bas Hamstra
Date: 09:07:23 08/18/99
Go up one level in this thread
Sigh. I wrote a long reply that disappeared. Ok, again. On August 18, 1999 at 05:45:05, Andrew Williams wrote: >On August 17, 1999 at 19:17:52, Bas Hamstra wrote: > >>On August 17, 1999 at 13:37:37, Andrew Williams wrote: >> >>>On August 17, 1999 at 11:18:05, Dan Homan wrote: >>> >>>>Do any programmer's have experience with Enchanced Transposition Cutoffs? >>>>It seems to me that these would be a fair amount of work at each node, but >>>>I was wondering if people generally find the payoff to be worth it. >>>> >>>> - Dan >>> >>>I've tried it twice in my program and both times found it unhelpful. >>>I think it might do better in my program if I tried a stripped-down >>>make_move, because I don't need (eg) my incremental updating of attack- >>>tables for the ETTC test. >>> >>>Andrew Williams >> >>Andrew, that's very interesting that you mention that incremental attacktables. >>I've been doing that for a long time (pseudo attacks, ie blocking pieces >>ignored) and achieved reasonable speed. About on par with Crafty. It gives a lot >>of handy advantes, both in capture generation (plus easy SEE) and eval. For >>every square of the board each of the 32 attackbits represented the attacking >>piece. >> > >Hello Bas, > >I think my program would be faster if I ignored blocking pieces in my >attack-tables (still nowhere near as fast as crafty, though). But how >useful are your attacktables if they ignore blocking pieces? It never >occurred to me to do it that way. Surely it wouldn't help your SEE if >you don't know if a piece can really attack a square. I'm wondering if >you perhaps mean "XRay attacks ignored"? Here is how I did it: I indeed only did pseudoattacks for reasons of speed. Sure, to see if a square is really attacked you need to check slider-attacks for blocks. Two things: - A very simple block() function (scanning squares) costs only 2%, says my profiler. So I don't worry about that. It's heavily used, and still only 2%. - In many cases, for example SEE, I *want* to have the pseudo attacks. Free "battery" detection, for example. Thirdly pseudo-attacks can be done pretty fast. I used a method that had all squares to "AND" or "OR" in code, to ensure that on assembly level only the mininum number of AND/OR operations is being performed, without ANY loop or memory lookup-overhead. Very fast. I wrote a routine that generates C code to generate the boring stuff (which squares to update etc). (fourth: Eval wise pseudo-attacks can be handy too) Regards, Bas Hamstra. >>too stripped and redid my make/unmake. You can't ever go faster than the >>make/unmake, how fast it may be. In fact I redid everything and spent a whole >>vacation experimenting. I just now made a breakthrough in figuring out which >>datastructures are fastest for capture- and attackgeneration. I hope to be able >>to tell more soon. Occasionally ideas work in practice too :) >> > >I'd be interested to hear any results you get. > >Best regards > >Andrew
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.