Efficient calculation of sliding piece mobility.
Moderator: Ras
-
- Posts: 18
- Joined: Mon Apr 10, 2023 6:33 am
- Full name: Jayden Joo
Efficient calculation of sliding piece mobility.
When implementing mobility in my evaluation function, the nps drops from 17 to 11 million. This slowdown comes from calculating sliding piece attack maps for both sides. Is there a more efficient way to calculate or estimate mobility for sliding pieces so my nps doesn’t plummet?
-
- Posts: 36
- Joined: Thu Mar 03, 2022 7:29 am
- Full name: Alvin Peng
Re: Efficient calculation of sliding piece mobility.
How are you calculating sliding piece attacks? Are you using magic bitboards? If you are, I don't think you can get much faster than that.
-
- Posts: 18
- Joined: Mon Apr 10, 2023 6:33 am
- Full name: Jayden Joo
Re: Efficient calculation of sliding piece mobility.
Yes, magic bitboards and popcnt. I'm not sure of a good way to incrementally update sliding piece attack maps, so I calculate them from scratch every time.alvinypeng wrote: ↑Tue Jul 18, 2023 3:00 pm How are you calculating sliding piece attacks? Are you using magic bitboards? If you are, I don't think you can get much faster than that.
-
- Posts: 18
- Joined: Mon Apr 10, 2023 6:33 am
- Full name: Jayden Joo
Re: Efficient calculation of sliding piece mobility.
EDIT: I managed to increase the NPS up to 13.6 million (from 11.3 mil) by partially using the results of the move generation (the quiscence search runs the move generation to make sure that there are no captures availivable).
-
- Posts: 28353
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: Efficient calculation of sliding piece mobility.
Calculate it incrementally, rather than from scratch.
If you already get the mobility of the stm as a side effect of the move generation, you could get the mobility of the opponent from the move generation in the parent. The only cause of slider mobility change after a capture (i.e. in QS) is discovery of slider moves by the moved (friendly) piece. And the common case is that no such moves are discovered at all, so that the work remains limited to the test to detect those.
If you already get the mobility of the stm as a side effect of the move generation, you could get the mobility of the opponent from the move generation in the parent. The only cause of slider mobility change after a capture (i.e. in QS) is discovery of slider moves by the moved (friendly) piece. And the common case is that no such moves are discovered at all, so that the work remains limited to the test to detect those.
-
- Posts: 18
- Joined: Mon Apr 10, 2023 6:33 am
- Full name: Jayden Joo
Re: Efficient calculation of sliding piece mobility.
Thanks. Why didn't I think of that before? Since most evaluated nodes are in QS, this should significantly speed things up. Unfortunately, I'll have to deal with that annoying en passant move again.
-
- Posts: 28353
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: Efficient calculation of sliding piece mobility.
Since Pawn double pushes are not captures there should also be no e.p. captures in QS.