Where to generate Attack Tables

[henkf]

Hi,

I'm designing a new engine and lately I've been thinking about Attack Tables, but I'm a bit unsure where to generate them. As I see it, they can be used for a lot of things, like SEE, move generation, move ordering and evaluation. However from what I have seen here most generate them in Eval. Doesn't this mean they have limited use, or am I overseeing something? Any ideas?

Brgds,

Henk

[sje]

The answer depends on exactly what is contained in the attack tables.

The general answer is that an attack database is generated whenever a new position appears via a new game event or a position setup event. The attack tables are then updated incrementally when a move is made or unmade.

[Ryan Benitez]

I am sure other people do something more creative but I generate a list of attack bitboards just before I need to detect in check then use them for detecting hanging pieces to narrow the futility cut off, move ordering, evasions, movegen, and many things in eval. Generating them in eval would only make sense to me if you are using a full eval at every node.

[Gerd Isenberg]

Ideal to generate attack sets from scratch is while "waiting" for a hash-probe, for instance x64 prefetch-instruction combined with SSE2 fill-stuff to compute sliding attacks.

[Edsel Apostol]

I am sure other people do something more creative but I generate a list of attack bitboards just before I need to detect in check then use them for detecting hanging pieces to narrow the futility cut off, move ordering, evasions, movegen, and many things in eval. Generating them in eval would only make sense to me if you are using a full eval at every node.

I do full eval in every node but I don't use the generated attack tables for other things except inside the eval. It seems I'm trying to do some redundant work on my move ordering and move generation. This gives me some ideas to make my engine faster. Thanks for the post.

[henkf]

I am sure other people do something more creative but I generate a list of attack bitboards just before I need to detect in check then use them for detecting hanging pieces to narrow the futility cut off, move ordering, evasions, movegen, and many things in eval. Generating them in eval would only make sense to me if you are using a full eval at every node.

I do full eval in every node but I don't use the generated attack tables for other things except inside the eval. It seems I'm trying to do some redundant work on my move ordering and move generation. This gives me some ideas to make my engine faster. Thanks for the post.

Do you currently hash eval? If this is the case speedup might not be spectacular, depends on your hitrate and how expensive your attack tables are of course. I am curious how it works out for you.

[henkf]

The answer depends on exactly what is contained in the attack tables.

The general answer is that an attack database is generated whenever a new position appears via a new game event or a position setup event. The attack tables are then updated incrementally when a move is made or unmade.

Thinking about incremental updates gives me a headache. But maybe that should be part of the fun. Is incrementally updating really faster? I'm using a 0x88 like board array which indexes to a piece[ 32 ] array. For the attack boards i'm thinking about two approaches. One I would call the Ed Schroder-approach i.e. maintaining per square a bitarray with attack information, and the other one would be a 64bitmap per piecelist entry. In both approaches I do not see how I could incrementally update the attack information without scanning the board. But maybe I should think a bit more.

[Edsel Apostol]

I am sure other people do something more creative but I generate a list of attack bitboards just before I need to detect in check then use them for detecting hanging pieces to narrow the futility cut off, move ordering, evasions, movegen, and many things in eval. Generating them in eval would only make sense to me if you are using a full eval at every node.

I do full eval in every node but I don't use the generated attack tables for other things except inside the eval. It seems I'm trying to do some redundant work on my move ordering and move generation. This gives me some ideas to make my engine faster. Thanks for the post.

Do you currently hash eval? If this is the case speedup might not be spectacular, depends on your hitrate and how expensive your attack tables are of course. I am curious how it works out for you.

I don't hash my eval. My attack tables are used in computing mobility, king attacks and passed pawn.

I'm thinking that if I could calculate it outside of the eval, I could also use it in other things like move generation, SEE, and it seems like a big savings in calculation.

Computation of piece attacks in my engine is not that expensive.

[henkf]

Ideal to generate attack sets from scratch is while "waiting" for a hash-probe, for instance x64 prefetch-instruction combined with SSE2 fill-stuff to compute sliding attacks.

Whoah... I'm a member since 1998 ( give or take a few years ), so maybe it's a bit late to introduce myself. I'm a professional business application programmer and I have always worked with high level programming languages ( 4GL's as they used to be called ). The only speed optimization I had ever to worry about where adding indexes to ( or refactoring ) slow queries. I'm a C/C++ autodidact and I am already happy I mastered the syntax.

Although I always find your posts interesting, I am not even close to the level where one would start to understand a small part of them.

Anyway I'm in the designing phase and didn't even think about hashing yet. But when I will come to it, I will put the probe right before the generation of the attack tables

[Matthias Gemuh]

Anyway I'm in the designing phase and didn't even think about hashing yet. But when I will come to it, I will put the probe right before the generation of the attack tables

Maybe Gerd's approach will only work for you if you prefetch cache lines into your registers and flood-fill them with SSE2 instructions and snoop64

Matthias.