Not logged inRybka Chess Community Forum
Up Topic Rybka Support & Discussion / Rybka Discussion / "Rotated bitboards is a trivial algorithm"
1 2 Previous Next  
Parent - By Banned for Life (Gold) Date 2013-09-14 18:42
Trivial - Mathematics denoting a subgroup that either contains only the identity element or is identical with the given group.

It just occurred to me that trivial has multiple meanings. When I said the algorithm was trivial, I meant that it involved only a change in ordering. I was not implying that the algorithm is unimportant or that it is obvious (although the concept is very simple).
Parent - - By Banned for Life (Gold) Date 2013-09-12 19:59
Good info. Thanks.

At that time (January 1997) there were 3 bitmap programs: Crafty, Spector and Dark Thought. Chess 4.x had retired by then but had used them as well. Others have tried but given up.

OK, aside from Spector, which never had much success, the others all had their roots in big hardware.

As bob put it at the time, the concept was at best break even on 32-bits systems with rotated boards, and a loss otherwise.

Bob must have been smarter back then...

But PC's with 64 bits were going to change everything in favour of bitmaps. Those weren't available to the common man at that time yet of course.

The DEC Alpha was the only reasonable alternative for a personal computer in 1997, and it was too pricey for most individuals. Ditto for the Intel Itanium which debuted in 2001. AMD didn't introduce x86 64-bit extensions until April 2003, and these didn't catch on until a year later.
Parent - - By bob (Gold) Date 2013-09-13 00:01
Never heard of theMIPS R10000?  Sun SPARC (64 bit version)?  ALL "early 90's" alongside the alpha.

There was 64 bit hardware to be had.  In 1996 or so, whenever the pentium pro 200 came out, a gateway computer sold for about $2500 with that P6 cpu.  We were buying 64 bit sparcs for just over $3000...
Parent - - By Banned for Life (Gold) Date 2013-09-13 01:14
There were 34 entries in the 1997 WCCC. Zero were using MIPS machines. Zero were using SPARC machines. Five were using DEC Alpha machines of  different vintages. The remaining 29 were using 32-bit Intel or AMD machines.

Would you like to bring up any other hardware that was way out of the mainstream?
Parent - - By bob (Gold) Date 2013-09-13 01:56 Edited 2013-09-13 02:04
Sorry, there were more 64 bit sparcs around than there were alpha workstations.  We had a lab full of sparc boxes.  I had exactly one alpha box, in my office, the only one we had at UAB that I am aware of...  Everybody had Sun ultra-sparcs (I think that's what they called 'em).  I taught our asm course on them for several years...

But the original point stands.  32 bit machines ran bitboard programs just fine.  Slate did quite well on a sub-64-bit machine.  As did I...
Parent - - By Banned for Life (Gold) Date 2013-09-13 03:01
You're having trouble reading again. Will it help if I make it bold?

There were 34 entries in the 1997 WCCC. Zero were using MIPS machines. Zero were using SPARC machines. Five were using DEC Alpha machines of  different vintages. The remaining 29 were using 32-bit Intel or AMD machines.

What part of that don't you understand?

DEC Alpha machines were much better represented in the WMCC than Sparc stations.

In the time period between 1995 and 2003 bitboard based engines were not common, nor were they particularly successful on mainstream hardware.
Parent - - By bob (Gold) Date 2013-09-13 04:07
Do you know why?  A couple of us got together, approached a company that I "think" was called "Cryotech", and they provided a group of machines for us to use.  There was an unreliability factor because they were over clocked.  They brought a couple of spares which were made available to anyone wanting to use them.  Bruce Moreland (Ferret) ran on one, WITHOUT bitboards, just because it was faster than anything Intel had...

In the time between 1995 and 2003 bitboard programs did just fine...

Once again, lots of bluster, no facts...
Parent - - By Banned for Life (Gold) Date 2013-09-13 05:38
Bruce Moreland (Ferret) ran on one, WITHOUT bitboards, just because it was faster than anything Intel had...

So did SMK.

In the time between 1995 and 2003 bitboard programs did just fine...

Sure. Eight events and one fourth place finish for 32-bit bitboard engines. That's a great record!
Parent - - By bob (Gold) Date 2013-09-13 15:50 Edited 2013-09-13 15:53
Keep it up.  :)

A little education:

CCT-1  2000.  Crafty #1.  Shredder #2.  Nimzo #3.  Junior #6.
CCT-2  2001.  Shredder #1, Crafty #2.
CCT-3  2001.  Crafty #11.
CCT-5  2003.  Crafty #1.
CCT-6  2004.  Crafty #1. Hiarcs #2.  Zappa #3.  Junior #4.  Rebel-12 #17
.
Yep, those bitboard programs had no chance...
Parent - - By Banned for Life (Gold) Date 2013-09-14 06:54
You were running on 64-bit hardware in CCT-6, so we'll throw that one right out. This was a discussion about the relative merits of bitboards on 32-bit hardware...

For CCT-5, three engines ended up with 7 points. Crafty was running on much faster hardware than Yace or Ruffian. In a nice touch, this web page declares Ruffian the winner of CCT-5, although it doesn't seem to have won any of the tiebreaks! :lol:
http://www.vrichey.de/cct5/

I'm not sure why you included CCT-3 in your list. Coming in 11th in this field with 4-1/2 out of 8 isn't anything to write home about, especially since you were running on the best hardware, and by a good margin.

In CCT-2 you got beaten by a full point by Shredder running on much slower hardware. There were four engines with 5-1/2 points and who came in second would depend on which tiebreak they were using.

In CCT-1, you won outright, but with only Chrilly, Amir, and Bruce having comparable hardware.

I looked though some of the games from these tournaments, and the quality of the books were just awful...
Parent - - By bob (Gold) Date 2013-09-14 17:28
Back to the issue at hand.  Were bit boards competitive or not, regardless of whether it was 32 bit hardware or 64 bit hardware?

Answer is an obvious "yes".  Mailbox vs bitboard does NOT determine the best program.  That's a small part of a chess engine.
Parent - - By Banned for Life (Gold) Date 2013-09-14 18:20
Once again, you are misstating the issue. Your claim was that bitboards were an improvement on 32-bit systems. My claim was that your claim was not supported by the facts.

Mailbox vs bitboard does NOT determine the best program.  That's a small part of a chess engine.
Now you're going off the other end. In a world of 64-bit machines, not using bitboards is a significant disadvantage.
Parent - - By bob (Gold) Date 2013-09-15 01:17
The only "facts" that count are actual performance measurements.  I, and several others, measured this stuff exhaustively in the mid-90's when I started to use 'em and got everyone's attention in doing so.  We compared move generation speed, make/unmake speed, and such.  Basic findings were (1) move generation is pretty-much break-even.  (2) ditto for make/unmake;  (3) a special case of move generation, however, is significantly faster with bitboards on 32 bit processors, that of generating nothing but captures.  (4) the real gains show up in loop elimination in the evaluation.  Which is a serious part of the overall time usage.

On 64 bit processors, the advantages widen the gap further.
Parent - - By Banned for Life (Gold) Date 2013-09-15 02:26
The only "facts" that count are actual performance measurements.  I, and several others, measured this stuff exhaustively in the mid-90's when I started to use 'em and got everyone's attention in doing so.  We compared move generation speed, make/unmake speed, and such.  Basic findings were (1) move generation is pretty-much break-even.  (2) ditto for make/unmake;  (3) a special case of move generation, however, is significantly faster with bitboards on 32 bit processors, that of generating nothing but captures.  (4) the real gains show up in loop elimination in the evaluation.  Which is a serious part of the overall time usage.

During the 32-bit era, developers interested in maximizing performance spent their time on improving their search, not in changing their board representation from mailbox to bitboard. It wasn't until the dawn of the 64-bit era in the early to mid 2000s that developers like Anthony and later Vas were using bitboards on commonplace hardware. Immediately prior to that, the developers of Fritz, Junior, Shredder and Fruit were the top engines, and all based on mailbox.

On 64 bit processors, the advantages widen the gap further.

When 64-bit processors became commonplace in 2004/2005, bitboards became de rigueur for top engines with differences of 30 to 64 Elo between 32 and 64 bit compiles for current top engines.
Parent - - By bob (Gold) Date 2013-09-15 14:16
I've not seen 64 elo for going to 64 bits.  That requires a 2x speed increase, which will not happen unless someone has a grossly ugly implementation of bitboards...

Common numbers are in the 25-30% speed improvement.
Parent - - By Banned for Life (Gold) Date 2013-09-15 17:37 Edited 2013-09-15 17:41
I've not seen 64 elo for going to 64 bits.  That requires a 2x speed increase, which will not happen unless someone has a grossly ugly implementation of bitboards...

Common numbers are in the 25-30% speed improvement.


This is certainly not true for top engines. In CCRL 40/40, Rybka and Komodo get a doubling in speed with 64-bit, while Critter, Houdini and Stockfish get a 50% speed up:

From CCRL 40/40
Single core, with ratings for both 64 and 32 bit implementations

   Rybka 4 64-bit  3094  +17  −17  68.0%  −122.1  40.4%  1250
   Rybka 4 32-bit  3017  +15  −15  68.3%  −117.6  45.4%  1429
Difference = 77 Elo

   Rybka 4.1 64-bit  3100  +11  −11  54.4%  −28.4          52.1%  2787
   Rybka 4.1 32-bit  3036  +12  −12  58.6%  −55.5          48.7%  2103
Difference = 64 Elo

   Rybka 3 64-bit  3054  +12  −12  67.7%  −125.5  39.2%  2689
   Rybka 3 32-bit  2996  +13  −13  73.5%  −159.2  37.7%  2151
Difference = 58 Elo

   Houdini 3 64-bit   3172  +14  −13  64.8%  −95.7          45.9%  1740
   Houdini 3 32-bit  3142  +20  −20  70.3%  −130.3  44.0%  838
Difference = 30 Elo

   Komodo 4 64-bit  3113  +11  −11  57.5%  −50.1          48.5%  2532
  Komodo 4 32-bit  3037  +17  −16  59.1%  −59.1          47.7%  1147
Difference = 76 Elo

   Komodo 5 64-bit  3122  +11  −11  57.9%  −50.0          51.5%  2681
   Komodo 5 32-bit  3053  +16  −16  58.4%  −51.5          52.3%  1132
Difference = 69 Elo

   Critter 1.6a 64-bit  3110  +13  −13  57.0%  −43.8  55.6%  1663
   Critter 1.6a 32-bit  3074  +16  −16  62.4%  −76.5  54.8%  1127
Difference = 36 Elo

   Stockfish 2.3.1 64-bit  3091  +17  −17  57.1%  −43.4  54.5%  1065
   Stockfish 2.3.1 32-bit  3047  +17  −17  57.2%  −45.2  50.5%  1095
Difference = 44 Elo
Parent - - By bob (Gold) Date 2013-09-15 22:26
Error bars are so large the numbers don't mean much at all.  64 bit hardware does NOT make a bitboard program go 2x faster.  Not even 1/2 of a chess program USES bitboards.  Recursive search.  Qsearch.  Hashing.  move ordering.  Etc.

Please keep trying, however...

And be sure to offer numbers with a 30-elo or larger window...
Parent - - By Banned for Life (Gold) Date 2013-09-15 23:10
Error bars are so large the numbers don't mean much at all.

Wrong! The two sigma error (95.44%) bars are given for each result. As an example, for Komodo 5 shown below, they are +/- 11 Elo for the 64-bit version and +/- 16 Elo for the 32-bit version. Meanwhile, the difference in Elo of the two engines is 69, meaning that the probability that the Elo difference between the two engines is less than 42 is less than 0.00052.

CCRL 40/40
   Komodo 5 64-bit  3122  +11  −11  57.9%  −50.0          51.5%  2681
   Komodo 5 32-bit  3053  +16  −16  58.4%  −51.5          52.3%  1132
Difference = 69 Elo

The CCRL differences for Komodo 4, Rybka 4.1, Rybka 4, and Rybka 3 are 76, 77, 64 and 58 Elo respectively.

Going to CEGT 40/20 we see:
24    Komodo CCT x64           3012   14   14   1200   59.7%   2944   47.6%
74   Komodo CCT w32   2938   23   23   450   50.1%   2938   47.8%
Difference = 74 Elo

64 bit hardware does NOT make a bitboard program go 2x faster.

Wrong. All of the top programs shown above are getting the equivalent of a 2X speedup by going from a 32-bit to a 64-bit build of the exact same program according to the testing groups.

Not even 1/2 of a chess program USES bitboards.  Recursive search.  Qsearch.  Hashing.  move ordering.  Etc.

Doesn't matter. The ratings lists did the tests. I've copied the results. The 32-bit builds may have other problems, but they are running at half speed compared to the 64-bit builds.

Please keep trying, however...

You are obviously too stupid to understand even simple statistics. It's very sad.
Parent - - By bob (Gold) Date 2013-09-16 01:01
1.  bitboards are NOT 2x faster on 64 bit hardware.  There are lots of bitboard operations (AND and OR in particular) that are just as fast on 32 bit as they are on 64 bit, because they fill in for pipeline stalls caused by dependencies. 

2.  programs are not 100% bitboard operations.  Search doesn't know bitboard from hula skirt.  All you have to do is profile an engine to see what the gain might be.  If you want to assume absolute best case, call it 2x faster, for the parts that use bitboards.  Look at the profile to see how much of the total time is spent doing pure bitboard stuff.  Add 'em up.  Maybe 50%.  Which means you see a 2x speedup on 50% of the code (IF you believe the 2x speedup which I know is wrong) and no speedup on the other 50%.  You now take 75% as long as you did on 32 bit hardware.  NOT 50%. 

Argue all you want about what was measured and what was seen by whomever you want.  Amdahl's law does not step aside for computer chess programs...
Parent - - By Banned for Life (Gold) Date 2013-09-16 02:04
1.  bitboards are NOT 2x faster on 64 bit hardware.  There are lots of bitboard operations (AND and OR in particular) that are just as fast on 32 bit as they are on 64 bit, because they fill in for pipeline stalls caused by dependencies.

2.  programs are not 100% bitboard operations.  Search doesn't know bitboard from hula skirt.  All you have to do is profile an engine to see what the gain might be.  If you want to assume absolute best case, call it 2x faster, for the parts that use bitboards.  Look at the profile to see how much of the total time is spent doing pure bitboard stuff.  Add 'em up.  Maybe 50%.  Which means you see a 2x speedup on 50% of the code (IF you believe the 2x speedup which I know is wrong) and no speedup on the other 50%.  You now take 75% as long as you did on 32 bit hardware.  NOT 50%.


Wrong. Once again, your argument that the approximately 2X speedup isn't happening is directly contradicted by the testing performed by the testing groups on many top bitboard engines. This large speedup is not observed with non bitboard engines. I do not know why this is the case, or why the difference is less for other engines, e.g. Houdini, which normally shows a ~30 Elo difference between 32-bit and 64-bit builds.

Argue all you want about what was measured and what was seen by whomever you want.  Amdahl's law does not step aside for computer chess programs...

This is a good example of the Aristotelian method used to convince people that heavy objects fall faster than lighter objects for 1900 years. The scientific method of testing has shown that in many cases, 64-bit build chess engines are approximately twice as fast as a 32-bit build of the same engine. This may be due to factors other than bitboards, but if the testing group data is valid, the speed ratio itself has been demonstrated.
Parent - - By bob (Gold) Date 2013-09-16 03:17
Please cite some "scientific testing".  I did such testing on both 32 bit AND 64 bit boxes many times.  Never saw 2x on ANY bitboard program I tested.  If it is 2x faster, NPS should double, period.  I've not seen that ever.  And I have tested it a TON.  On EQUIVALENT hardware.  IE a 32 bit and 64 bit compile run on SAME 64 bit box.  Some programs are somewhat poorly written internally, and the 8 extra registers in 64 bit mode might give them a larger than expected boost.  But that is NOT related to bit boards...
Parent - - By Banned for Life (Gold) Date 2013-09-16 04:01 Edited 2013-09-16 04:17
Please cite some "scientific testing".

The CCRL and CEGT lists are good examples of scientific testing under controlled circumstances. They are not subject to the bias that is encountered when people test their own work.

I did such testing on both 32 bit AND 64 bit boxes many times.  Never saw 2x on ANY bitboard program I tested.  If it is 2x faster, NPS should double, period.  I've not seen that ever.  And I have tested it a TON.  On EQUIVALENT hardware.

CCRL and CEGT test for Elo. They don't give a fig about NPS. Elo is a much better metric than NPS. NPS is only interesting as a method of predicting Elo.

IE a 32 bit and 64 bit compile run on SAME 64 bit box.

Vas did all of his development in 64-bits and wasn't even going to release Rybka 1.0 Beta in 32-bits. He relented and did a 32-bit build, but was very open about not performing any optimization on the 32-bit builds. I suspect Don is doing the same thing.

Some programs are somewhat poorly written internally, and the 8 extra registers in 64 bit mode might give them a larger than expected boost.  But that is NOT related to bit boards...

That may be. I suspect it could be due to alignment problems, since 64-bit compilers tend to align to 16-byte boundaries while 32-bit compilers tend to align to 8-byte boundaries. These stalls are easy to check for on a profiler, but I don't have any of the 32-bit engines installed on chess boxes. But for whatever reason, for the engines referenced, there is a much larger than expected increase in Elo when using the 64-bit build, while for non-bitboard programs, 64-bit builds tend to be not much stronger than 32-bit builds.
Parent - By Adam Hair (**) Date 2013-09-16 11:19

> Please cite some "scientific testing".
>
> The CCRL and CEGT lists are good examples of scientific testing under controlled circumstances. They are not subject to the bias that is encountered when people test their own work.


The lists are not perfect, but they are good enough for these sorts of comparisons.

> I did such testing on both 32 bit AND 64 bit boxes many times.  Never saw 2x on ANY bitboard program I tested.  If it is 2x faster, NPS should double, period.  I've not seen that ever.  And I have tested it a TON.  On EQUIVALENT hardware.
>
> CCRL and CEGT test for Elo. They don't give a fig about NPS. Elo is a much better metric than NPS. NPS is only interesting as a method of predicting Elo.


I do not get the insistence for citing NPS when we all know that the effectiveness of any aspect of a chess engine is measured by Elo. On that note, here are some additional numbers:

Stockfish 1.7.1 64-bit  3018  +22  -22
Stockfish 1.7.1 32-bit  2972  +18  -18

Difference = 46

Gull 1.2 64-bit          2925  +17  -17
Gull 1.2 32-bit          2876  +13  -13

Difference = 49

Gull 1.1 64-bit          2921  +21  -21
Gull 1.1 32-bit          2881  +17  -17

Difference = 40

Spark 1.0 64-bit      2901  +15  -15
Spark 1.0 32-bit      2868  +12  -12

Difference = 33

Spark 0.3 64-bit      2841  +18  -18
Spark 0.3 32-bit      2799  +16  -16

Difference = 42

Protector 1.4.0 64-bit  2916  +16  -16
Protector 1.4.0 32-bit  2879  +12  -12

Difference = 37

>
> IE a 32 bit and 64 bit compile run on SAME 64 bit box.
>
> Vas did all of his development in 64-bits and wasn't even going to release Rybka 1.0 Beta in 32-bits. He relented and did a 32-bit build, but was very open about not performing any optimization on the 32-bit builds. I suspect Don is doing the same thing.


That is correct. Don does not spend any time optimizing for 32-bit.

>
> Some programs are somewhat poorly written internally, and the 8 extra registers in 64 bit mode might give them a larger than expected boost.  But that is NOT related to bit boards...
>
> That may be. I suspect it could be due to alignment problems, since 64-bit compilers tend to align to 16-byte boundaries while 32-bit compilers tend to align to 8-byte boundaries. These stalls are easy to check for on a profiler, but I don't have any of the 32-bit engines installed on chess boxes. But for whatever reason, for the engines referenced, there is a much larger than expected increase in Elo when using the 64-bit build, while for non-bitboard programs, 64-bit builds tend to be not much stronger than 32-bit builds.


That has been my experience.
Parent - - By user923005 (****) Date 2013-09-14 20:04
I sort of disagree.  I think that to write the strongest program today, it is a mistake to chose an array based system.
Now, if the array based program has other things that are better, it can be stronger.  But I think that on 64 bit CPUs with 64 bit operating systems, using bitboards is a substantial advantage.
A couple of ands and shifts and I can tell if I have built a wall with my sliders.  How many instructions to do it with an array?
1r2kq2/4p3/3pPp2/2pP1Pp1/1pP3N1/pP4K1/P7/7R w - -

Similarly, a couple shifts and ands to generate all pawn moves, similarly for captures.

On the other hand, if someone is writing their first chess program, an array based system might seem more natural to them.  So for that purpose, it is probably a very good fit.
Parent - - By bob (Gold) Date 2013-09-15 01:14
What do you disagree with?  I have REPEATEDLY stated (a) bitboards on 32 bit machines are at WORST a break-even in terms of move generation and make/unmake, while in the eval, if it is written "bitboardy" there is a speed advantage even on 32 bit machines;  (b) on 64 bit machines it is the most logical approach, although the gain is STILL not enormous.  But it is significant...

Bitboards work REGARDLESS of the architecture.  Chess 4.x won multiple ACM chess tournaments, using a 60 bit CDC that required two words for each 64 bit bit-board...  Seemed to work out pretty well for 'em.
Parent - - By user923005 (****) Date 2013-09-15 05:21
I think you should read my post again.
Parent - - By bob (Gold) Date 2013-09-15 14:15
I read what you wrote.  bitboards worked quite well on 32 bit machines and had a small performance increase thanks to bit-parallel operations in evaluation.  Movgen was a wash, but that's only part of the story.  In Crafty, for example, evaluation > 5x more computation than move generation.
Parent - - By user923005 (****) Date 2013-09-16 02:49
I said: I think that to write the strongest program today, it is a mistake to chose an array based system.

Considering what I said, I do not understand your response.
Parent - - By bob (Gold) Date 2013-09-16 03:15
Sorry, I looked at your "I sort of disagree".  But I take issue with any criticism of bitboards, whether 32 bit or 64 bit architecture.  They are effective on both, at LEAST as good as array-based stuff...
Parent - - By user923005 (****) Date 2013-09-16 07:42
Somewhere else I made the point that I don't think anyone knows whether array or bitboard is superior on 32 bit systems.
I figured that you only read the first sentence of my post before you responded to it.
Parent - - By bob (Gold) Date 2013-09-16 13:27
Some of us DO know about bitboard vs array on non-64 bit architectures.  Do you believe Slate decided to use something that was not better, since he had no expectation of seeing anything but 60 bit words on the CDC hardware?

You can go back to late 1994 and look at the discussions on r.g.c.c.  I decided to investigate the idea right after the 1994 ACM event.  Several of us did lots of tests to see how this stuff would work on 32 bit machines, because my GOAL for the rewrite was to move to the PC, not to continue to use Cray's indefinitely.  Everyone focuses on the double instructions needed to do 64 bit ops on a 32 bit machine.  Shows a lack of understanding of architectural details.  Even the lowly pentium, in use in 1994, had dual instruction pipes, but could not keep both pipes busy most of the time.  Along comes a bitboard program and suddenly both run almost saturated.  The extra instructions disappear into the second pipe most of the time.  And now we have the good side. (1) generating all moves is pretty similar in speed to mailbox.  (2) generating captures is a BIG win for bitboards, because we don't have to loop over all the empty squares.  (3) evaluation becomes more efficient.  Overall, it is a net gain.  Of course, 64 bit hardware improves that "gain", but not by the 2x being bandied about.  The extra 8 registers help most programs more than the longer word length.
Parent - By user923005 (****) Date 2013-09-16 18:10
I don't think we have any accurate measures to prove whether 64-bit bitboards are better or worse on 32 bit architectures.  A simple piece list can save a lot of the extra work of examining blank squares.  Of course, the bitboards are built in piece lists, so that you do not have to maintain separate piece lists with bitboards.  I pretty much agree with all of your points and I do know that you understand the hardware architecture of many systems better than I do.

I am not surprised that bitboards worked well on a CDC cyber. I got to do Fortran on one a long time ago.  If I recall correctly, it was considered to be the world's first supercomputer.
Fortran was really funky on the CDC cyber, because characters had to be packed and unpacked into the 60 bit words.
It was a lot more fiddly than on the IBM 360 and 370 that I was used to.
Parent - - By Rebel (****) Date 2013-09-12 20:00
How much would you estimate the speed gain of standard bit-boards vs rotated bit-boards vs magic bit-boards?
Parent - By user923005 (****) Date 2013-09-12 23:55
I know that rotated bitboards are faster than non-rotated bitboards, but I do not know the ratio.
Magic bitboards are not appreciably faster than rotated bitboards.  They are a lot less complex, so they are easier to maintain.
There was a program called Elephant that had a zillion different bitboard implementations.
Probably, that would be a good place to test the different bitboard strategies for speed.  Of course, not all implementations are equal.
Parent - By bob (Gold) Date 2013-09-13 00:06
Rotated is about 15% faster than normal bitboards.  Magic produced no speed gain for me.  I like it because it is more convenient to use.  If you want to do a tricky move generation, with rotated boards you have to update 4 separate occupancy boards first.  With magic, just one.  Simpler...
Parent - By bob (Gold) Date 2013-09-13 00:04
There were more.  Joel Rivat (France) wrote a program named "ChessGuru".  Played for a year or two on ICS (at the time before it became ICC and started charging).  There were others, although I do not claim to remember all the names.  It was not a "rare thing"...  There was "Cricket", "Falcon" at least, to name a couple more.  I'll see what I can dig up.
Parent - By user923005 (****) Date 2013-09-12 06:17
Rotated bitboards and lockless hash tables were both original, interesting and valuable ideas.
Rotated bitboards have been superceded by magic bitboards, but the lockless hash tables are still incredibly useful.
Up Topic Rybka Support & Discussion / Rybka Discussion / "Rotated bitboards is a trivial algorithm"
1 2 Previous Next  

Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill