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
Generating "through" attacks with rotated bitboard
Moderators: hgm, Rebel, chrisw
-
- Posts: 879
- Joined: Mon Dec 15, 2008 11:45 am
-
- Posts: 879
- Joined: Mon Dec 15, 2008 11:45 am
Re: Generating "through" attacks with rotated bitb
PS: (last post)
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).
Desperado wrote: ...
I only proposed OD (as buildup), ...
That means, i dont want to replace something, i think it is cheapGerd Isenberg wrote: 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.
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).
-
- Posts: 2250
- Joined: Wed Mar 08, 2006 8:47 pm
- Location: Hattingen, Germany
Re: Generating "through" attacks with rotated bitb
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.Desperado wrote:PS: (last post)
Desperado wrote: ...
I only proposed OD (as buildup), ...That means, i dont want to replace something, i think it is cheapGerd Isenberg wrote: 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.
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).
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...
-
- Posts: 879
- Joined: Mon Dec 15, 2008 11:45 am
Re: Generating "through" attacks with rotated bitb
Yes. Like someone said : "Never stop a running system".Gerd Isenberg wrote:
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...
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.
-
- Posts: 20943
- Joined: Mon Feb 27, 2006 7:30 pm
- Location: Birmingham, AL
Re: Generating "through" attacks with rotated bitb
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.Gerd Isenberg wrote: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.Desperado wrote:PS: (last post)
Desperado wrote: ...
I only proposed OD (as buildup), ...That means, i dont want to replace something, i think it is cheapGerd Isenberg wrote: 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.
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).
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 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.
-
- Posts: 161
- Joined: Thu Jan 08, 2009 9:06 pm
- Location: San Francisco, USA
Re: Generating "through" attacks with rotated bitb
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 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.
-
- Posts: 20943
- Joined: Mon Feb 27, 2006 7:30 pm
- Location: Birmingham, AL
Re: Generating "through" attacks with rotated bitb
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.vladstamate wrote: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.