Author: Robert Hyatt
Date: 11:34:21 11/19/02
Go up one level in this thread
On November 19, 2002 at 14:24:04, Vincent Diepeveen wrote: >On November 19, 2002 at 14:11:18, Robert Hyatt wrote: > >>On November 19, 2002 at 12:25:11, Gian-Carlo Pascutto wrote: >> >>>On November 19, 2002 at 11:35:24, Robert Hyatt wrote: >>> >>>>Bitboards have a bit of a performance advantage on 64 bit processors, >>> >>>Proof? >>> >>>-- >>>GCP >> >>Counter-proof? >> >>Seems intuitively obvious to me. Bitmaps seem to suffer _no_ performance >>penalty on >>X86 with 32 bits, compared to 0x88. Seems intuitively obvious to me that they >>will pick >>up speed on a machine that does 64 bit operations. >> >>Bruce and I did this comparison when he used the alpha in the WMCCC (1997 I >>think). >> >>He re-compiled ferret for the alpha, did the same for Crafty. My speed >>improvement was >>significantly better than his on the _same_ machine. Because of the 64 bit >>stuff. His program >>didn't need any 64 bit stuff so it was wasted... >> >>Best "proof" is to try it. I have... > >But at that time i also proofed that you generated moves already 2.2 times >slower than i did. If you then get 33% faster because of getting 64 bits, >that doesn't proof anything. OK... let's pick a common architecture and generate moves from a position you choose. What processor/speed do you want to use? I have a bunch here, from 400mhz to 550 to 700 to 750 to 800 to 1.4ghz that I can get to easily. > >If we look at the speed at specint of crafty versus specint of K7, >then we see that a 1Ghz alpha 21264c, which is their fastest CPU, >is performing at the OFFICIAL benchmark like a 1.33Ghz K7. > >So if we roughly give you 33% for bitboards going from 32 to 64 bits, >then that's simply the maximum you can claim for it. 33% is significant, is it not??? And I get it _free_... to boot... > >The argument that specint is not allowing inline assembly is not valid. >I do not use inline assembly in my program either (with exception of >locking at the x86). So let's keep it a fair compare. > >So first a slowdown of a factor 2 (used to be 2.2) then winning back >33% because of getting 64 bits, that isn't very impressive to me. I know. 10% is impressive when you want it to be. 33% is not when you don't want it to be... When we had the discussion about null-move not hurting SMP performance, it dropped from 3.1x faster to 3.0 faster when null-move was turned on. That was significant to you. When we had the speedup discussion where I said Crafty was 1.7X faster on a dual and you said it was 1.6X faster, that was significant. But 1.0 vs 1.3 is not significant, because you don't want it to be??? > >It sure is intuitively VERY CLEAR to me that just >having 1 bit of info spreaded over loads of bitboards is not >a very good plan, because for any complex chess pattern you >simply need more instructions than non-bitboarders do. It might be clear to you. Fortunately, for those of us doing this stuff, we are not quite that rigid in our thinking, and we find solutions to problems that you say can't be solved. The flood-fill stuff was one interesting discussion that you will have a hell of a time doing in a non-bitboard program... there are other cases where bitmaps might be worse. But there are just as many where they are better. As I said I don't see _any_ advantage except that on 64 bit machines they are faster due to increased data density.
This page took 0.07 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.