Bitboard implementation, how much time?

[Evert]

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.

Wrong.
I can switch between Kindergarten and rotated bitboards in Jazz by changing a compile-time option. The only thing that changes is the way a number of functions are implemented (the functions that extract the occupancy numbers and the functions that initialise the lookup tables, since the way I deal with "extra" bits in the case of rotated bitboards is different). Every other part of the program (including the move generator) remains the same.
It all depends on how you set up your data structures and the functions that operate on them.

[bob]

Hmm, reading the numbers here is doesn't seem too unlikely that someone who knows Crafty can rewrite fruit within a few weeks/monthes to bitboards...


Bye
Ingo

My answer was based on "starting from scratch." That is, "how long to figure out how to do the move generation, write/debug/test the code, and then fit the rest of the framework around it to make it play chess.

Cray Blitz was retired in late 1994. I had already started (sometime in october maybe) to look at bitboard ideas. By Christmas, Crafty was playing on ICC, although it was anything but "very strong". If someone wanted to "bitboard" fruit, given some help such as the bitboard paper I wrote in the ICGA or the online board representation paper on my web site, they could probably pull that off in a month or so of steady work. Lots of things to change, and lots of code to write from scratch. If copying is OK, then that could likely be cut down to maybe 1-2 weeks to get a bitboard fruit up and going.

[Desperado]

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.

Wrong.
I can switch between Kindergarten and rotated bitboards in Jazz by changing a compile-time option. The only thing that changes is the way a number of functions are implemented (the functions that extract the occupancy numbers and the functions that initialise the lookup tables, since the way I deal with "extra" bits in the case of rotated bitboards is different). Every other part of the program (including the move generator) remains the same.
It all depends on how you set up your data structures and the functions that operate on them.

Hi, Evert,

your are right of course. With a good preparation and a well design
of the data structures it is of course possible, and viewing it from
this perspective, everything is possible.

What i meant was, that the listed attackGetters with hidden implementation,
are completly independant what happens elsewhere in
the code. No need to look at the data structures or to think about
compile switches. Only the attackGetter functions themselves must be changed.

Or as simple question, how many code lines you would have to change
in your complete code, _without_ compile switches , if you switch
from Rotated to any other bitboard technique ? (excluding the
attackgetter functions themselves)

For the listed approaches, the answer is _zero_ !

regards,

Michael

[michiguel]

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.

Wrong.
I can switch between Kindergarten and rotated bitboards in Jazz by changing a compile-time option. The only thing that changes is the way a number of functions are implemented (the functions that extract the occupancy numbers and the functions that initialise the lookup tables, since the way I deal with "extra" bits in the case of rotated bitboards is different). Every other part of the program (including the move generator) remains the same.
It all depends on how you set up your data structures and the functions that operate on them.

Hi, Evert,

your are right of course. With a good preparation and a well design
of the data structures it is of course possible, and viewing it from
this perspective, everything is possible.

What i meant was, that the listed attackGetters with hidden implementation,
are completly independant what happens elsewhere in
the code. No need to look at the data structures or to think about
compile switches. Only the attackGetter functions themselves must be changed.

Or as simple question, how many code lines you would have to change
in your complete code, _without_ compile switches , if you switch
from Rotated to any other bitboard technique ? (excluding the
attackgetter functions themselves)

For the listed approaches, the answer is _zero_ !

regards,

Michael

Correct, it could be even possible to make a library lib.so with my approach, replace it later with magics, KG etc. and the code will not even be touched.

With the rotated approached it is necessary to maintain an extra quad bitboard.

Miguel

[IWB]

Hmm, reading the numbers here is doesn't seem too unlikely that someone who knows Crafty can rewrite fruit within a few weeks/monthes to bitboards...


Bye
Ingo

My answer was based on "starting from scratch." That is, "how long to figure out how to do the move generation, write/debug/test the code, and then fit the rest of the framework around it to make it play chess.

Cray Blitz was retired in late 1994. I had already started (sometime in october maybe) to look at bitboard ideas. By Christmas, Crafty was playing on ICC, although it was anything but "very strong". If someone wanted to "bitboard" fruit, given some help such as the bitboard paper I wrote in the ICGA or the online board representation paper on my web site, they could probably pull that off in a month or so of steady work. Lots of things to change, and lots of code to write from scratch. If copying is OK, then that could likely be cut down to maybe 1-2 weeks to get a bitboard fruit up and going.

Thx for the answer.
Actualy that would be a nice add to the engine pool. Someone take the last open source fruit and convert it to bitboards while trying to stay as close to the original code as possible. I would definately give that 64bit engine a run in the IPON (and would add the source code of Fruit which was used as well)

Someone volunteers?

Bye
Ingo

[hgm]

That would just slow it down, right? Staying close to the original, in stead of doing the extra things that are cheap with bitboards to recoup the losses you suffer by using the less efficient representation.

[IWB]

That would just slow it down, right? Staying close to the original, in stead of doing the extra things that are cheap with bitboards to recoup the losses you suffer by using the less efficient representation.

No no,you are right, that is what I ment. Of course all improvement regarding bitboards should be implemented.
A "reasonable bitboard implementaion" of Fruit (of course accepting the GPL ), that is what I like to test ...

Go for it

Bye
Ingo

[Rebel]

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 definitely like this. I was considering Kindergarten.

Thanks!

[bob]

That would just slow it down, right? Staying close to the original, in stead of doing the extra things that are cheap with bitboards to recoup the losses you suffer by using the less efficient representation.

I don't think so. Might not be a big gain, or even a slight gain, but I wouldn't think it would hurt, so long as it was a true conversion and not just a quick and dirty "let's get this done" as opposed to "let's compute the exact same things, but do it in a 'bitboardy' way..." Say SEE() and Eval specifically...

[mjlef]

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 definitely like this. I was considering Kindergarten.

Thanks!

Does this mean Ed might be starting work on a new program! That would be great.