Bitboard implementation, how much time?

[Desperado]

Hello, Ed,

i think that implementing the attack getter functions, will take _about_ the
same time for both, magics or rotated, _if_ you are already familiar with those
techniques.

But because the complete code will be riddled with bitboard solutions, considering

* easy condition checks, up to...
* different kind of bitboard solutions,functions (like: see example)
* complete code chunks(eg SEE) or ...
* even complete rewrite of moduls like the move generator

example:

Code: Select all

static bb_t getInBetween(sq_t sq0,sq_t sq1)
{
    bb_t tmp = 0;

    if(tmp = mask_shared_line[sq0][sq1])
    {
        tmp &= &#40;allbits << sq0&#41; ^ &#40;allbits << sq1&#41;;
        tmp &= tmp-1;
    &#125;

    return&#40;tmp&#41;;
&#125;

the better choice (IMHO) is to invest your time into the magic bitboard approach.

In the long run, you will save time using magics,
even it _would_ take less time to inroduce rotated because you _might_ already know rotated
but might not be familiar with magics.

Beside the fact, that the rotated approach _still_ belongs to the fastest approaches,
one really disadvantage is (imo), that is part of the board representation. Other
approaches like magics can handle _temporarily_ bitboard states much more easily, so
you will find more general solutions, and more general solutions will save time in a
long run, and provide more elegant and faster solutions too.

Now, my advice to you is in any case, _not_ to do a simple replacement of the attack-getter
functions, but to write the code from scratch. This will take some weeks, _but_
otherwise you will see in some weeks, that _most_ of your existing code is suboptimal with
respect to bitboards and you will start anyway from scratch. (My experience some years ago,
going from x88 approach to bitboards).

imho, regards

Michael

[Desperado]

PS:

the given example is _only_ initialization code, but could even be
considered as direct computation of "inBetween" states. Just as
side note.

Michael

[hgm]

My guess is that Ed is not asking this because he actually wants to do it.

[Desperado]

My guess is that Ed is not asking this because he actually wants to do it.

Yes, indeed, there _might_ be another background.
But anyway, the topic can be handled as what it is for many programmers
out there too.

A simple question about how to change board representation
and to go with bitboards some day without loosing to much time.

Whatever motivation Ed does have, there is no need for a discussion
on his motivation (at this place), but only on the topic. (IMHO )

regards,

Michael

[michiguel]

My guess is that Ed is not asking this because he actually wants to do it.

In another thread he mentioned he wants to translate his program to 64 bits but he is worried about wasting time with bugs.

Miguel

[hgm]

That is not the same as translating to bitboards, right?

[michiguel]

How much time did it take you to convert:

1. Mailbox -> Rotated bitboard
2. Mailbox -> Magic bitboard

And have it 100% bug free.

I started in the late 90's to write a rotated approach from scratch. In fact, that was done at the same time I was learning C and quitting pascal. It took me probably a couple of months, at a rate of ~2 hours per day. That was the only thing I had, a generator. But, rotated approaches are a mess (carrying around quad bitboards or pointers to them is really inconvenient). Magic will make your head spin until you understand what the heck is going on. None of that is actually CC per se...

If you are planning to do this, forget about 1 and 2 and consider what I do in Gaviota
http://www.talkchess.com/forum/viewtopic.php?t=30356

It is way much simpler, easy to understand, easy to debug, and if in the future to want to do magics, the interface will be identical so you just replace the internal code w/o affecting anything from your program, **AND** you will have a working approach to compare and debug the magic procedure.
Is it slower? probably, but I doubt you will notice it in a working engine. For me, it is nothing when I profile it. But, like I said, moving from this to magics will be very easy.

Of course you can use the code in that post (quite short, actually), but I am sure you will find ways to optimize it (particularly knowing your experience and expertise in ASM).

Advantages: it uses very little memory and the code is short.

Miguel

[Evert]

If you are planning to do this, forget about 1 and 2 and consider what I do in Gaviota
http://www.talkchess.com/forum/viewtopic.php?t=30356

It is way much simpler, easy to understand, easy to debug, and if in the future to want to do magics, the interface will be identical so you just replace the internal code w/o affecting anything from your program, **AND** you will have a working approach to compare and debug the magic procedure.
Is it slower? probably, but I doubt you will notice it in a working engine. For me, it is nothing when I profile it. But, like I said, moving from this to magics will be very easy.

Of course you can use the code in that post (quite short, actually), but I am sure you will find ways to optimize it (particularly knowing your experience and expertise in ASM).

Advantages: it uses very little memory and the code is short.

Interesting. I should take a look at something like that for Sjaak, which uses a *lot* of lookup tables. Anything that reduces cache pressure will probably help it.

[michiguel]

That is not the same as translating to bitboards, right?

I know, but he said bitboard
http://www.talkchess.com/forum/viewtopi ... ugs#445795

Miguel

[Desperado]

How much time did it take you to convert:

1. Mailbox -> Rotated bitboard
2. Mailbox -> Magic bitboard

And have it 100% bug free.

I started in the late 90's to write a rotated approach from scratch. In fact, that was done at the same time I was learning C and quitting pascal. It took me probably a couple of months, at a rate of ~2 hours per day. That was the only thing I had, a generator. But, rotated approaches are a mess (carrying around quad bitboards or pointers to them is really inconvenient). Magic will make your head spin until you understand what the heck is going on. None of that is actually CC per se...

If you are planning to do this, forget about 1 and 2 and consider what I do in Gaviota
http://www.talkchess.com/forum/viewtopic.php?t=30356

It is way much simpler, easy to understand, easy to debug, and if in the future to want to do magics, the interface will be identical so you just replace the internal code w/o affecting anything from your program, **AND** you will have a working approach to compare and debug the magic procedure.
Is it slower? probably, but I doubt you will notice it in a working engine. For me, it is nothing when I profile it. But, like I said, moving from this to magics will be very easy.

Of course you can use the code in that post (quite short, actually), but I am sure you will find ways to optimize it (particularly knowing your experience and expertise in ASM).

Advantages: it uses very little memory and the code is short.

Miguel

I agree totally to seperate the attackGetter as own interface.
The hidden implementation approach allows a change within "minutes".
My guess is that it wouldnt take longer than 10 to 15 min to change
from my current attackGetter to Miguels proposal.

No need to touch other code parts, and the oppertunity to jump
between magics,Kindergaten,Miguel's approach or even OD.
(maybe many others too) is fantastic.

That is in fact _not_ possible with Rotated bitboards.

Michael