Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Differences between 0x88 ,10x12 and Bitboards!?

Author: Robert Hyatt

Date: 11:22:27 11/19/02

Go up one level in this thread


On November 19, 2002 at 13:57:02, Vincent Diepeveen wrote:

>On November 19, 2002 at 13:30:57, Christophe Theron wrote:
>
>>On November 19, 2002 at 13:15:09, Gerd Isenberg 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
>>>
>>>Hi Gian-Carlo,
>>>
>>>I think that's evident. If the none bitboarders have to use implicite native
>>>data-width of 64 bit integers, they have to transfer 32 additional zero bits
>>>without any additional information for each integer access. Of course you will
>>>pack some data, but all the local ints...
>>>
>>>So the information density for bitboarders grows with 64bit-architectures
>>>relative to none bitboarders. That also effects register usage, and that's IMHO
>>>more important. On x86-32bit architectures you can only hold three bitboards in
>>>registers, and thats even most a hard task. Actually, if you have a local
>>>routine with three bitboards and a few ints on the stack, there are a lot
>>>register/memory moves. Simply the data-width doubles the number of bitboard
>>>registers, not considered the increase in general purpose registers, or with
>>>hammer the number of mmx- and 128-bit xmm registers.
>>>
>>>Whether a bitboard based program is stronger than a none bitboard program
>>>depends obviuosly also on other things, but in principle :)
>>>
>>>Cheers,
>>>Gerd
>>
>>
>>
>>You have just explained why the bitboarders are less handicapped on 64 bits
>>machines.
>>
>>You have not explained why they are supposed to have "a bit of performance
>>advantage on 64 bits processors".
>>
>>
>>
>>    Christophe
>
>Exactly,
>
>But more important is that they are not in the same league at 32 bits
>processors with knowledge. As soon as they need more knowledge they
>run into problems. My move generation in itself eats 0.6% of the system
>time. My evaluation nearly all of it.
>\



That is crap.  Crap.  MORE CRAP.

Anything you can do with your current data structure, I can do with bitmaps.

And I do mean _anything_...

Please give _one_ example of something that I _can't_ do with bitmaps.


>Yet a crucial aspect of evaluating is scanning and that's something
>where bitboards are handicapped with 1 or 2 exceptions (you can
>quickly scan a rank or file for presence of a piece X). So at 64
>bits CPUs a hybrid model is something which is possible but the
>majority of the cases just having 1 bit available with bitboards
>and needing an extra
>array lookup to index all the different arrays for having the bit
>set true, that's pretty slow.
>
>Yet if you keep your program dumb and fast, you don't suffer from
>that lack of course and will never be able to realize it.
>
>In which case there is no advantage of course, because crafty is
>at a McKinley like 1.5MLN nodes a second, whereas a program which
>is equally weak tactical last so many plies and in qsearch (saving
>out loads of system time which most stronger programs prefer to
>spent there), to make it in non-bitboards, is easily going to
>get the same number of nps with those blazing fast 6 instruction
>bundles a clock.


again, crap, more crap and more crap.

you can wave your hands.  You can repeat that as many times as you want...

but it won't make it true...

you don't understand bitmaps.  you haven't spent the necessary time to learn how
to
do them.  you once told me that I couldn't do "decent mobility" on a Cray where
I
would have a different value for each square.  I showed you how to do it easily
and
quickly, even though you said "you can't do that."

This is more of the same...

Just because you can't write code to do something, doesn't mean everybody else
can't do it either.

The "shift/compare" post from Eugene was a classic.  you can't do that.  Eugene
shows you that you can.  So you switch to "but that compiler can't be used, or
it is
too expensive, or it makes it too easy to disassemble or ..."

And once again, you end up dead wrong...

as usual.

Why not let the people that know about bitboards talk about them?  And the ones
that want
to _learn_ about them learn about them?



>
>In a simple experiment of mine where i just did recaptures based
>upon a single simplistic attacktable in qsearch (only generated
>that attacktable at root in qsearch not the innernodes in qsearch),
>i got at a P5-100 already blazingly fast. 200k nps initially. When
>i then tried to search deeper it got down to 100-150k nps, depending
>whether i tried to do less in qsearch or more.


You really can't follow a discussion at all.  My q-search is simple for _one_
reason.
My early q-searches did checks.  They did check escapes.  you can look at the
comments
in main.c to see when that was removed.  I removed it because I liked the
program better
with a simple q-search so that I could work on extensions in the normal search
without
worrying about q-search explosions.  It is _not_ simple because I want it to be
fast, in terms
of NPS.  It is not simple because I can't do checks in the q-search.  It is
simple because in a
discussion Bruce and I had prior to the Jakarta WMCCC event, he had removed
q-search checks
and liked the result and he told me about it.  I removed them and also decided
that I liked the
result.

not for the reason _you_ are giving, however.



>
>In all these cases bitboards is a major handicap at 32 bits processors
>and at 64 bits processors the % you lose to bitboards versus non bitboards
>is depending upon non-bitboards code in the search simply.

It is a _terrible_ handicap.  That is why there are _several_ bitboarders
running
today.  It is so terrible that Frans decided to wreck his program by going to
use them.





>
>Best regards,
>Vincent



This page took 0.03 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.