Generating "through" attacks with rotated bitboard

[Desperado]

Hi Gerd,

well it s comprehensible, the way you argue. But my only itention
was to note, that there is a possibility to become aquainted with another
bitboard approach without writing anything from scratch.

_At the end_, someone will (should!) decide for one approach(avoiding
any kind of overhead), in which someone will see the most potential.
(doesnt matter if it is: rotated,magic,KG,OD or any other, being a matter
of taste and needs.)

I only proposed OD (as buildup), because it is very easy to implement (not much work i mean. the masks may be already exist, so only the lineattack()),
and someone can see some behaviors atypical for rotated, but typical for other bitboard approaches.(perhaps it already pays off at this point)

For the most important gain, to learn sth, you dont have to spend much additional effort. And then you can make your decision,
cleaving to rotated, merge rotated+xy, or even writing from scratch.

(At last, i see a great potential due to ROD idea, so in the rotated approach which i dont have at hand, it _could_ be a great buildup.
i am not able to answer this question, because i dont have any rotated
bitboards or any similar frame)

best regards, Michael

[Desperado]

PS: (last post)

...
I only proposed OD (as buildup), ...

Changing those aspects is much more work than replacing the pure attack-getter api. It is more error-prone for very little gain, if any.

That means, i dont want to replace something, i think it is cheap
enough to have it as additional utility(for a while at least),
until you know its pros/cons.
Then, if needed, a decision can be done, like i tried to explain in my post before.
(and perhaps both harmonize,complement very well, for only adding one function.
Two attacker apis must not be redundant in total).

[Gerd Isenberg]

PS: (last post)

...
I only proposed OD (as buildup), ...

Changing those aspects is much more work than replacing the pure attack-getter api. It is more error-prone for very little gain, if any.

That means, i dont want to replace something, i think it is cheap
enough to have it as additional utility(for a while at least),
until you know its pros/cons.
Then, if needed, a decision can be done, like i tried to explain in my post before.
(and perhaps both harmonize,complement very well, for only adding one function.
Two attacker apis must not be redundant in total).

You are right, OD and HQ need very little memory resources, which are most often already available. The normal occupancy is available as well, so that a concurrent api might be used, f.i. to implement X-ray stuff with temporarily changed occupancy inside a register. But there are 32-bit issues, you need to take care, and not everyone likes to have a bunch of #ifdefs for various architectures, e.g. HQ for K8/K10 and OD for core2 and Kindergarten for 32-bit systems.

My point was, if you have developed your engine over years, and you are happy with rotated bitboards, all is running fine and smoothly, and you concentrate on lowering branching factor and smarter search and eval, you are probably not that interested to eventually speed up in the < 1% range, with the chance (as every change) to introduce some new obscure bugs...

[Desperado]

My point was, if you have developed your engine over years, and you are happy with rotated bitboards, all is running fine and smoothly, and you concentrate on lowering branching factor and smarter search and eval, you are probably not that interested to eventually speed up in the < 1% range, with the chance (as every change) to introduce some new obscure bugs...

Yes. Like someone said : "Never stop a running system".

But before i am gonna to enjoy the evening without chessprogamming ( is this possible ? ), i like to add that i dont had performance issues in
mind at all. Easier code, can also help avoiding mysterious bugs, and so on...

At the end i think, everyone has to decide by him/herself to try out some
new ways or not, which can lead in 2 directions (bad,good).

So thx Gerd for your reply, always welcome

nice weekend to everyone.

[bob]

PS: (last post)

...
I only proposed OD (as buildup), ...

Changing those aspects is much more work than replacing the pure attack-getter api. It is more error-prone for very little gain, if any.

That means, i dont want to replace something, i think it is cheap
enough to have it as additional utility(for a while at least),
until you know its pros/cons.
Then, if needed, a decision can be done, like i tried to explain in my post before.
(and perhaps both harmonize,complement very well, for only adding one function.
Two attacker apis must not be redundant in total).

You are right, OD and HQ need very little memory resources, which are most often already available. The normal occupancy is available as well, so that a concurrent api might be used, f.i. to implement X-ray stuff with temporarily changed occupancy inside a register. But there are 32-bit issues, you need to take care, and not everyone likes to have a bunch of #ifdefs for various architectures, e.g. HQ for K8/K10 and OD for core2 and Kindergarten for 32-bit systems.

My point was, if you have developed your engine over years, and you are happy with rotated bitboards, all is running fine and smoothly, and you concentrate on lowering branching factor and smarter search and eval, you are probably not that interested to eventually speed up in the < 1% range, with the chance (as every change) to introduce some new obscure bugs...

I added magic generation to Crafty with zero pain. I had always used Macros to hide the ugly rotated bitboard table lookups. I simply changed the macros, and included the necessary initialization code in place of the rotated table initialization. I didn't see any speed improvement, but I liked the ability to modify just the OccupiedSquares bitboard to generate a new set of attacks with an existing piece removed.

I remember writing the initial rotated bitboard stuff in about 8 hours, on a drive from Birmingham to Orlando (with my wife driving). Keeping the three extra bitboards added to the code, and that goes away with magic. IMHO smaller is usually always better.

[vladstamate]

I think I might have to learn and implement the magic bitboards in Plisk. I have now working xray attacks in SEE however, my speed dropped to half when I added those in. Granted some of it it is to do with fluff from my data structure but there just seems to be a lot of work to get the attack-throughs calculations using rotated bitboards.. Definitely more than in the code posted by Gerd above.

I am using SEE as a means to order captures (if the capturing piece is more valuable than the captured piece). And I am using it in both normal search and QS, so it gets called a lot.

Regards,
Vlad.

[bob]

I think I might have to learn and implement the magic bitboards in Plisk. I have now working xray attacks in SEE however, my speed dropped to half when I added those in. Granted some of it it is to do with fluff from my data structure but there just seems to be a lot of work to get the attack-throughs calculations using rotated bitboards.. Definitely more than in the code posted by Gerd above.

I am using SEE as a means to order captures (if the capturing piece is more valuable than the captured piece). And I am using it in both normal search and QS, so it gets called a lot.

Regards,
Vlad.

I use it the same way, however in Crafty SEE accounts for less than 10% of the total execution time, so even if it were made twice as slow, it would have a minimal effect on overall search speed.