Speedup with bitboards on 64-bit CPUs

[Pradu]

I think it has been reported here Rybka, which Vasik says uses bitboards, runs about 60% faster on a 64 bit processor. I think the speed difference will depend greatly on what is being represented with 64 bit values.

60% is a lot, but of course we don't know exactly what Rybka is doing. Does anyone have any numbers for Crafty, SmarThink or other bitboard engines?

Lately, I have kept my mailbox move generation, but use some incrementally update bitboards too. In this hybrid approach, pawn attacks, knight attacks and king attacks can easily be update with a could of simple XORs. I have a bit for each pawn position, so detection of isolated and passed pawns is very fast (not much faster than the older array poitning to the least advanced pawn on each file though). I then OR in other attacks for sweep pieces for mobility/space control and so on. Of course my program is very slow anyway.

So is mine. My program with a material only eval is slower than Crafty with a full eval.

Tord

I get 2.2x speedup for Buzz from 32-bits to 64-bits on Core2. There's an open-source version of my program so you can see exactly what I'm doing.

[Pradu]

I would not expect any speedup from bitboards compaired to mailbox, even in 64-bit mode, if you jsut use them to replace the move generator. For bulk move generation bitboards cannot beat mailbox. They are very much faster than mailbox for generating moves selectively (e.g. only captures, only checks), though. But if your program should be doing that a lot in order to see any benefits.

I do generate moves incrementally with bitboards, and have separate move generation functions for captures, checks, non-captures and check evasions. But move generation doesn't consume a significant fraction of the CPU time in my program in any case, neither with bitboards nor with mailbox. The places where bitboards seem to be significantly slower are king safety evaluation, scanning for attacks in a single direction, and making and unmaking moves.

Tord

Making and unmaking moves is slow for bitboard regardless. But perhaps you can optimize your kingsafety code with either flood-filling or specialized magic routines and have it be significantly faster than mailbox for this. I haven't looked into Glaurung to see how you do kingsafety but I suppose it is the usual way of counting the number/type of attackers to squares around the king. It is quite strange scanning for attacks in a single direction is faster for you, do you have a SEE to bench for mailbox and bitboards?

[CRoberson]

Telepath (bitboard) is slower than NoonianChess in NPS by about 2x using a 32 bit complier (g++) for both on a Core2Duo and an AMD 4400+.
Both machines using a 32 bit version of windows.

When I went to the newer version of MSVC, Telepath gained a 33% speedup and it still was a 32 bit compile running on a 32 bit OS.

When I recompiled Telepath with g++ (64 bit version) and ran on the AMD with a 64 bit version of Linux, Telepath was 20% faster than NoonianChess was.

Telepath is bitboard (nonrotated) and NoonianChess uses a 64 element array and two piecelists.

[jdart]

Arasan uses bitboards extensively (including rotated). The 64-bit version is faster but not by much (10-25%). I am not sure why.

--Jon

[Michael Sherwin]

Arasan uses bitboards extensively (including rotated). The 64-bit version is faster but not by much (10-25%). I am not sure why.

--Jon

Rotated bitboards use lots and lots of multidimentional look-ups which is great for 32 bit processors, because it keeps 64 bit access to a minimum. However, when compiled for 64 bits all the same array indexing must be done and 64 bit access is still minimized. There are other bitboard methods that minimize look-ups and maximize 64 operations that run much faster on 64 bit processors when compiled to 64 bit code.

[jswaff]

60% is a lot, but of course we don't know exactly what Rybka is doing. Does anyone have any numbers for Crafty, SmarThink or other bitboard engines?

I don't have an exact figure, but Prophet's speedup is significant. On my 2ghz Core Duo I would typically see NPS's in the low 200's while playing on ICC. On my wife's AMD64 3200+ (2.2ghz I think) it is right around 500knps.

If I get a chance next week I'll try to take some measurements, but I'm sure it's a significant speedup. I know I won't be able to until at least Tuesday evening, but I should have some time after that.

Oh, Prophet is a rotated bitboard engine BTW. Prophet is also open source, you can get it at http://chessprogramming.org/prophet .

--
James

[frankp]

This strikes a cord. I was writing a new 0x88 program for the Palm z22 I bought recently, but it was just too slow (on the pc) so I have gone back to bitboards mainly because this is the way I think. Eval on 0x88 was so hard. I guess it is familiarity that matters. There seems no intrinsic reason why 0x88 would not be as fast. (Bitboards will be no good for the z22 of course.).

To answer your question, IIRC my old bitboard program got the order of 50% speedup moving to amd64 (gcc/Linux), but does not use rotated bitboards.

Frank

[bob]

I would not expect any speedup from bitboards compaired to mailbox, even in 64-bit mode, if you jsut use them to replace the move generator. For bulk move generation bitboards cannot beat mailbox. They are very much faster than mailbox for generating moves selectively (e.g. only captures, only checks), though. But if your program should be doing that a lot in order to see any benefits.

I do generate moves incrementally with bitboards, and have separate move generation functions for captures, checks, non-captures and check evasions. But move generation doesn't consume a significant fraction of the CPU time in my program in any case, neither with bitboards nor with mailbox. The places where bitboards seem to be significantly slower are king safety evaluation, scanning for attacks in a single direction, and making and unmaking moves.

Tord

I suspect you just need some "seat time" to get acclimated. "scanning for attacks" is a bad idea. We don't want to "scan" for anything in bitboards...

[bob]

Arasan uses bitboards extensively (including rotated). The 64-bit version is faster but not by much (10-25%). I am not sure why.

--Jon

Rotated bitboards use lots and lots of multidimentional look-ups which is great for 32 bit processors, because it keeps 64 bit access to a minimum. However, when compiled for 64 bits all the same array indexing must be done and 64 bit access is still minimized. There are other bitboard methods that minimize look-ups and maximize 64 operations that run much faster on 64 bit processors when compiled to 64 bit code.

I haven't found anything "much faster". I tested magic move generation and found it to be identical in speed with the rotated bitmaps I used in older versions. I converted to magic because they are simpler, but not because they are faster. There are a couple of advantages about being able to update one "occupied" bitmap and get moves from that, but for normal stuff, the two approaches are really equal if done properly. And since move generation is a small part of most chess programs, it doesn't make a hill of beans worth of difference no matter what approach you use, bitmaps or mailbox. The advantage of bitmaps lies elsewhere.

[Michael Sherwin]

Arasan uses bitboards extensively (including rotated). The 64-bit version is faster but not by much (10-25%). I am not sure why.

--Jon

Rotated bitboards use lots and lots of multidimentional look-ups which is great for 32 bit processors, because it keeps 64 bit access to a minimum. However, when compiled for 64 bits all the same array indexing must be done and 64 bit access is still minimized. There are other bitboard methods that minimize look-ups and maximize 64 operations that run much faster on 64 bit processors when compiled to 64 bit code.

I haven't found anything "much faster". I tested magic move generation and found it to be identical in speed with the rotated bitmaps I used in older versions. I converted to magic because they are simpler, but not because they are faster. There are a couple of advantages about being able to update one "occupied" bitmap and get moves from that, but for normal stuff, the two approaches are really equal if done properly. And since move generation is a small part of most chess programs, it doesn't make a hill of beans worth of difference no matter what approach you use, bitmaps or mailbox. The advantage of bitmaps lies elsewhere.

Magic is very interesting, no doubt about that, but the 64 bit multiplication is exspensive and the huge data tables that are required stresses the resources available to the processor on lesser hardware. Newer processors with humungous cashes are a different story. What also matters is how 'large the eval is compared to the move generator. In programs with smaller evals the speed difference is substantial. When I compiled Crafty to 64 bits on typical hardware there was about a 30% speedup. And for my program, RomiChess, the speedup going to 64 bit was 50%. I use the real old fashion bitboards that you describe in one of your papers. Although, I reinvented them prior to reading that paper.

I have developed (but not fully implemented) two new bitboard move generators that are faster than magic on both 32 bit and 64 bit machines. I hope to finish this work and publish some results in the coming months.