Author: Robert Hyatt
Date: 13:09:47 11/19/02
Go up one level in this thread
On November 19, 2002 at 15:04:15, Vincent Diepeveen wrote: >On November 19, 2002 at 14:34:21, Robert Hyatt wrote: > >Significant is that you first slow down your thing 2 times >at a few points in order to get 33% faster later at the >same points you first got 2 times slower. I don't believe that I "first slowed my thing down 2x". that is a statement _you_ have made. We can compare move generator speeds. If yours is faster, then that proves your move generator is faster. We then have to compare the important part which is evaluation. You pick some complex idea you think you excel at and I'll do it with bitmaps and we can compare those. I'll bet that bitmaps make up that loss pretty quickly in the evaluation due to the inherent "bit-parallel" operations that can be done. > >Anyway, by the time we all have 64 bits machines writing >chessknowledge in bitboards is too cryptic anyway. Programming >in a neat general way is always preferred above the bitboard >hacking with inline assembly and things like writing only >simplistic 1 line patterns IMHO. I have +lots+ of "patterns" that are not one line. For example, I compute a bitmap that shows where _every_ pawn can safely advance to, so that I can use that to see which pawns are weak and which are not. If that is "simplistic" then I'll eat it.. > >Best regards, >Vincent > >>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 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.