Computer Chess Club Archives




Subject: Re: significant math

Author: Vincent Diepeveen

Date: 21:00:13 11/21/02

Go up one level in this thread

On November 20, 2002 at 17:37:08, Sune Fischer wrote:

>On November 20, 2002 at 16:52:11, Dan Andersson wrote:
>>>Why does this matter?  The point is that a bitmap program and a non-bitmap
>>>are playing with equal skill.  If you want to take the position that one of the
>>>is very good and the other is very bad, that's ok.  I know my programming skill.
>>> I can't
>>>speak for anybody else.  So that leaves us at "yace is poorly written and Crafty
>>>is well-written
>>>so the comparison is invalid."
>>>I don't buy that...
>>You don't have to. And I can only conclude that your sometimes overactive
>>imagination made you think that. And that has nothing whatsoever to do with the
>>issues discussed. The issue IMO is would any one of the programs would benefit
>>from a different data representation. And what will happen on a 64 bit machine.
>>Not some veak claim of: Since these two programs are of similar strength. I
>>therefore conlude I am right. Weak logic. Handvaving and apples and oranges is
>>what I read. Not that I believe that you are wrong. But the fact is that you
>>make a claim and when you are asked to back it up. You resort to very shaky
>>lines of reasoning.
>There are two ways of arguing this I think. Either you go into some minute
>detail and say - 0x88 have advantage/disadvantage here or whatever.
>That leads nowhere, because of the counter argument: it is all about getting the
>best out of your data structure, everything has some weaknesses and some

I do not agree here with the assumption. Your assumption is that
knowledge A is a bit faster with bitboards so should be used with
bitboards and knowledge B is way faster with non-bitboards (0x88 is
not my favourite for C by the way, pregenerated tables are doing
fine in C).

My assumption is that i want A+B and some more and the increasing
knowledge in all commercial and also amateur chessprograms (i hate
making that distinction by the way, only the effort put in an engine
counts IMHO, not whether you are by accident commercial or not)
definitely gives a good thought on that that is exactly what happens.

Now i want both A+B and then it is not so difficult to define what
is faster on 32 bits machines.

The question now is whether a pure bitboard program is going to do
A+B faster at bitboards, not whether it's just doing A fast.

To give concrete logics here: at 64 bits machines a 64 bits
pawnboard is superb compared to my 32 bits vector boards i use
for pawnstructure now. Not for everything, but for a lot of
patterns i can save out 1 instruction.

However doing things in 64 bits at a 32 bits processor is more
than 1 instruction more, so i'll be not doing any effort to implement
that yet. Such a change is done in 1 week of work anyway, so
it is not really relevant anyway.

In case of a 64 bits machine i obviously will add such a bitboard
to my datastructure.

If i understand well, Quest which is a complete non-bitboarder IMHO,
is already using a pawnboard in MMX registers.

That doesn't make it a bitboarder at all IMHO. that's just a very
small part of Quest.

I'm not a hacker in assembly of course. Such a fulltime hacking job
i do not have time for. So i'll wait for true 64 bits processors
to add that pawnboard.

Now let's adress move generation and attacktables and normal
patterns. No way to do that at a 64 bits machine in bitboards
at the same speed. Not even close!

So my choice is not a very difficult one. It's pregenerated tables.
I could have gone for 0x88 too. There is no real big difference
between pregenerated tables and 0x88. In C i just prefer the
so called 'pregenerated'.

I prefer calling it non-bitboards or the John Stanback datastructure :)

Best regards,

>Therefore any technical detail will not be a very good measure of what is the
>best way overall.
>The second way is just as lose, but no less correct: do we see bitboarders
>having a great handicap relative to other datatypes?
>The answer is no, Crafty is doing fine among the amateurs, in spite of being
>open source!
>Now, we can go back and forth saying it's faster or slower, it's just moot, only
>the final product - the engine, matters.
>C or C++, bitboards or 0x88, very much same kind of debate IMO.

>>MvH Dan Andersson

This page took 0.09 seconds to execute

