Computer Chess Club Archives




Subject: significant math

Author: Vincent Diepeveen

Date: 12:04:15 11/19/02

Go up one level in this thread

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.

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.

Best regards,

>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,
>>>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
>>>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
>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
>it to be...
>When we had the discussion about null-move not hurting SMP performance, it
>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
>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.19 seconds to execute

Last modified: Thu, 07 Jul 11 08:48:38 -0700

Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.