bitboards like mailbox

[tcusr]

after reading this thread https://talkchess.com/forum3/viewtopic.php?f=7&t=77133 i came to the conclusion that this guy is right, why generate the moves in one go when we then iterate them one by one?
i still want to use bitboards so i wrote a function that shifts a bitboard to a desired direction and then immediately add the move to the move list, like you do in mailbox engines. this method works for sliders and the king but i still have not found a way to elegantly add knight moves, any solution that i can use to avoid a lookup table?
i soon i realized that this method is not efficient for the generations of captures. i decided to use kogge stone generators for rook/bishop/queen and do the usual stuff to add the moves (AND with opponent bitboard and iterate them) but i feel like this is slow (95 instructions for 4 directions).

i'm not an expert at this stuff but does the absence of the magic lookup table (0.8 to 3 MB) compensate for the slowness of the kogge stone algorithm?
am i overthinking since move generation is not the most expensive part an engine?
i mainly want to do this because it's my original implementation and i don't want to copy other engines for the magic tables stuff

[dangi12012]

i'm not an expert at this stuff but does the absence of the magic lookup table (0.8 to 3 MB) compensate for the slowness of the kogge stone algorithm?
am i overthinking since move generation is not the most expensive part an engine?
i mainly want to do this because it's my original implementation and i don't want to copy other engines for the magic tables stuff

This is the best quote here. Originality yields new algorithms and too many engines I look at - look exactly like one another! Its not good to start from a copy of another git repo. Start from scratch and develop your ideas.
The best way to answer your question is to implement an algorithm and test the resuts.

The result you get in terms of moves / s on kiwipete and other positions yields how good the idea is for a movegenerator.

For example I implemented many many algorithms and found out that some are insanely fast - but block other optimisations reguarding enpassant etc. The one advantage bitboards have that no one can counter is that move pruning is a single operation on all moves. So no if for checks and no single if statement for pinned pieces.
For example when a piece is pinned or the king is in check all conditional branching needed in mailslots goes away and the result is two simple AND instructions. Nothing will ever be faster.

Also asking in a forum only ever yields already known informations. When you want to push into new terretory its best to just implement and share the results

[tcusr]

i'm not an expert at this stuff but does the absence of the magic lookup table (0.8 to 3 MB) compensate for the slowness of the kogge stone algorithm?
am i overthinking since move generation is not the most expensive part an engine?
i mainly want to do this because it's my original implementation and i don't want to copy other engines for the magic tables stuff

This is the best quote here. Originality yields new algorithms and too many engines I look at - look exactly like one another! Its not good to start from a copy of another git repo. Start from scratch and develop your ideas.
The best way to answer your question is to implement an algorithm and test the resuts.

The result you get in terms of moves / s on kiwipete and other positions yields how good the idea is for a movegenerator.

For example I implemented many many algorithms and found out that some are insanely fast - but block other optimisations reguarding enpassant etc. The one advantage bitboards have that no one can counter is that move pruning is a single operation on all moves. So no if for checks and no single if statement for pinned pieces.
For example when a piece is pinned or the king is in check all conditional branching needed in mailslots goes away and the result is two simple AND instructions. Nothing will ever be faster.

Also asking in a forum only ever yields already known informations. When you want to push into new terretory its best to just implement and share the results

alright, i'll try and see how it goes, thanks

[odomobo]

... but i still have not found a way to elegantly add knight moves, any solution that i can use to avoid a lookup table?

The knight lookup table (and king) is the smallest, at 64 squares * 8 bytes = 512 bytes. Each index is a bitboard of potential knight destinations, where each destination is independent (thanks to lack of sliding). If you're concerned about cache pressure, then you should still consider a lookup table for knights (and king).

To your broader question, I have the opinion that there's a reason most serious engines use magics.

[hgm]

Lack of originality?

[tcusr]

Lack of originality?

yes? i've learnt most of the stuff i know from other (bitboard) engines so whenever i wanted to try something new i thought 'let me see how x does it'...
i tried to write a mailbox engine by reading qperft's code but it's too complicated for me

[hgm]

Well, let me put it this way: I don't think that there are very many engines around that have tried several different board representations and methods of move generation during their development. The reason these engine use what they use is thus not "we tried all possibilities, and this turned out to be fastest". Likely their authors just picked an example to see 'how it is done', and copied ('re-implemented' sounds more friendly) what that example did, whithout questioning why it did it that way.

[dangi12012]

Lack of originality?

yes? i've learnt most of the stuff i know from other (bitboard) engines so whenever i wanted to try something new i thought 'let me see how x does it'...
i tried to write a mailbox engine by reading qperft's code but it's too complicated for me

If you want something new and better - you dont walk the trodden path. End result could be better or worse. Either way you gain insights that most people dont get.

[tcusr]

before writing a move generator with this method i still have some doubts
to generate captures should i use another algorithm better suited for bitboards instead of the technique 'loop (for me shift) toward a direction until an enemy piece is met' used by mailbox engines? a rook/bishop can at most capture 4 pieces so maybe it's better to do 'RookAttacks(sq, occ) & Them' and then iterate the possible attacks but i have not found a fast and a small enough algorithm to generate moves on the fly
i have this problem only because in quiescence i have to generate captures, otherwise i would just generate quite and captures moves together.

[dangi12012]

before writing a move generator with this method i still have some doubts
to generate captures should i use another algorithm better suited for bitboards instead of the technique 'loop (for me shift) toward a direction until an enemy piece is met' used by mailbox engines? a rook/bishop can at most capture 4 pieces so maybe it's better

You can hide the implementation behind an interface and just replace it later and start with what you feel more confortable.
When you find something faster just replace the implementation and nothin else changes.

for sliders I have: Lookup::Rook(uint64_t occupy, in square);

where Lookup is a namespace.