Are Bitboards More Intoxicating Than They Are Good?

Discussion of chess software programming and technical issues.

Moderators: hgm, Dann Corbit, Harvey Williamson

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
User avatar
mvanthoor
Posts: 986
Joined: Wed Jul 03, 2019 2:42 pm
Location: Netherlands
Full name: Marcel Vanthoor
Contact:

Re: Are Bitboards More Intoxicating Than They Are Good?

Post by mvanthoor » Wed Feb 24, 2021 7:45 pm

hgm wrote:
Wed Feb 24, 2021 7:20 pm
So what would you say if I produced a mailbox engine that was 30% faster than magic bitboard? :roll:
I would start to doubt the sanity of the universe and jump off a building, completely expecting that I'll be able to fly...

Or I might look into your code and find out that you just added "nps *= 1.4" to it :lol:
Author of Rustic.
Releases | Code | Docs

User avatar
hgm
Posts: 26134
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: Are Bitboards More Intoxicating Than They Are Good?

Post by hgm » Wed Feb 24, 2021 7:55 pm

The Houdini trick!

mar
Posts: 2397
Joined: Fri Nov 26, 2010 1:00 pm
Location: Czech Republic
Full name: Martin Sedlak

Re: Are Bitboards More Intoxicating Than They Are Good?

Post by mar » Wed Feb 24, 2021 9:00 pm

mvanthoor wrote:
Wed Feb 24, 2021 7:45 pm
I would start to doubt the sanity of the universe and jump off a building, completely expecting that I'll be able to fly...

Or I might look into your code and find out that you just added "nps *= 1.4" to it :lol:
careful what you wish for, Marcel :) and what if both can pull it off?
Martin Sedlak

User avatar
mvanthoor
Posts: 986
Joined: Wed Jul 03, 2019 2:42 pm
Location: Netherlands
Full name: Marcel Vanthoor
Contact:

Re: Are Bitboards More Intoxicating Than They Are Good?

Post by mvanthoor » Wed Feb 24, 2021 9:32 pm

hgm wrote:
Wed Feb 24, 2021 7:55 pm
The Houdini trick!
Oh... Houdini actually did that to LOOK faster? Sad. I haven't followed that affair because I never owned Houdini. I've been a Fritz / Morsch guy with regard to engines (before I got into open source).
mar wrote:
Wed Feb 24, 2021 9:00 pm
careful what you wish for, Marcel :) and what if both can pull it off?
Then the entire world just has to abandon magic bitboards and start over.

Or we get into the actual universe-destroying situation where HGM's mailbox engine is faster than Mike's SISSY bitboards, but also the other way around. And when you play them against one another in the end, the result of the match will always be a draw, despite both engines winning all of their games. Some sort of a Shrödinger's Quantum State Affair Cat Thing.
Author of Rustic.
Releases | Code | Docs

User avatar
hgm
Posts: 26134
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: Are Bitboards More Intoxicating Than They Are Good?

Post by hgm » Wed Feb 24, 2021 9:39 pm

mvanthoor wrote:
Wed Feb 24, 2021 9:32 pm
Oh... Houdini actually did that to LOOK faster? Sad.
Well, it was not really a factor 1.4, but 1.125. I suppose it wanted to disguise that it had switched from being an Ippolit derivative to being a Stockfish derivative, by suggesting that the strength improvement was due to a speed increase.

Joost Buijs
Posts: 1296
Joined: Thu Jul 16, 2009 8:47 am
Location: Almere, The Netherlands

Re: Are Bitboards More Intoxicating Than They Are Good?

Post by Joost Buijs » Thu Feb 25, 2021 9:50 am

mvanthoor wrote:
Wed Feb 24, 2021 7:12 pm
Don't you _DARE_ make any bitboards faster than magics, because then I'd have to rewrite my move generator. You don't want to be responsible for causing weeks of hardship and suffering to other people, do you? Please keep this new bitboard variant 1% slower than magics. (Add a few useless statements that the compiler can't remove, if you have to.) Thanks for your consideration.
PEXT bitboards are clearly faster than magics because you don't need the multiply and the shift. Why don't you use these?

All current Intel processors and AMD since Zen3 support this, so there is no reason not to use these.

With magics it is:
return magic->attacks[(magic->mask & blockers) * magic->mult >> magic->shift];

With PEXT:
return magic->attacks[_pext(blockers, magic->mask)];

Just a tiny modification but faster.

mar
Posts: 2397
Joined: Fri Nov 26, 2010 1:00 pm
Location: Czech Republic
Full name: Martin Sedlak

Re: Are Bitboards More Intoxicating Than They Are Good?

Post by mar » Thu Feb 25, 2021 10:05 am

Joost Buijs wrote:
Thu Feb 25, 2021 9:50 am
PEXT bitboards are clearly faster than magics because you don't need the multiply and the shift. Why don't you use these?

All current Intel processors and AMD since Zen3 support this, so there is no reason not to use these.

With magics it is:
return magic->attacks[(magic->mask & blockers) * magic->mult >> magic->shift];

With PEXT:
return magic->attacks[_pext(blockers, magic->mask)];

Just a tiny modification but faster.
but isn't pext emulated (and thus much slower) on (older) AMD chips?
also how do you use pext on ARM CPUs? is there a similar instruction/intrinsic that does the same?

magics are still portable

out of curiosity - how much faster (engine overall) is the pext version? I can't try it myself because I have a Zen2 (I believe) CPU
Martin Sedlak

User avatar
mvanthoor
Posts: 986
Joined: Wed Jul 03, 2019 2:42 pm
Location: Netherlands
Full name: Marcel Vanthoor
Contact:

Re: Are Bitboards More Intoxicating Than They Are Good?

Post by mvanthoor » Thu Feb 25, 2021 11:03 am

Joost Buijs wrote:
Thu Feb 25, 2021 9:50 am
PEXT bitboards are clearly faster than magics because you don't need the multiply and the shift. Why don't you use these?

All current Intel processors and AMD since Zen3 support this, so there is no reason not to use these.

With magics it is:
return magic->attacks[(magic->mask & blockers) * magic->mult >> magic->shift];

With PEXT:
return magic->attacks[_pext(blockers, magic->mask)];

Just a tiny modification but faster.
As some engines can be compiled to use both magic and PEXT bitbords, I assume I can just add some functionality, and don't have to rewrite my entire move generator from scratch. If that'd be the case, I'd not do it. (Not at this point, anyway.)
Author of Rustic.
Releases | Code | Docs

Joost Buijs
Posts: 1296
Joined: Thu Jul 16, 2009 8:47 am
Location: Almere, The Netherlands

Re: Are Bitboards More Intoxicating Than They Are Good?

Post by Joost Buijs » Thu Feb 25, 2021 11:13 am

mar wrote:
Thu Feb 25, 2021 10:05 am

but isn't pext emulated (and thus much slower) on (older) AMD chips?
also how do you use pext on ARM CPUs? is there a similar instruction/intrinsic that does the same?

magics are still portable

out of curiosity - how much faster (engine overall) is the pext version? I can't try it myself because I have a Zen2 (I believe) CPU
I just mentioned this because Marcel was talking about differences of 1%.

The difference in speed on the engine overall is not much, overhere I measure ~2% speed increase when I use PEXT. On older AMD CPU's PEXT is unusable slow, ARM does not have this instruction at all.

On Intel/AMD you can use CPUID to determine on which processor the engine runs and automatically switch between PEXT/magics. For ARM you need a separate build anyway.

User avatar
hgm
Posts: 26134
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: Are Bitboards More Intoxicating Than They Are Good?

Post by hgm » Sun Feb 28, 2021 10:25 am

Mike Sherwin wrote:
Wed Feb 24, 2021 5:54 pm
In Carnivor only material counting and psqt evaluation are done and it is also incremental. And everytime a move is made in search the nodes counter is incremented. So for example searching to 13 ply deep takes 17.42 seconds and 448,943,111 moves are made. On my calculator 448943111 / 17.42 = 25,771,705 moves per second.
I still want to understand this better, because it is unusually fast. So I am curious what exactly you are doing here.

You mention you count making moves, and this might cause tricky differences, as I am used to counting move generations. So what kind of search is this, exactly? Is there a quiescence search? Is there futility pruning?

I ask that, because futility pruning dispenses with moves without actually making them. This of course makes the engine faster, which is why we do it. But if you count makemoves, it would make the nps go down. So I am a bit worried that the high nps could be a consequences of making mostly useless moves, to nodes for which you knew in advance you did not have to do anything there.

Post Reply