TalkChess.com

hgm wrote: ↑Wed Feb 24, 2021 8:20 pm So what would you say if I produced a mailbox engine that was 30% faster than magic bitboard?

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

The Houdini trick!

mvanthoor wrote: ↑Wed Feb 24, 2021 8: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

careful what you wish for, Marcel and what if both can pull it off?

hgm wrote: ↑Wed Feb 24, 2021 8:55 pmThe 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 10: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.

mvanthoor wrote: ↑Wed Feb 24, 2021 10:32 pmOh... 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.

mvanthoor wrote: ↑Wed Feb 24, 2021 8: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.

Joost Buijs wrote: ↑Thu Feb 25, 2021 10: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

Joost Buijs wrote: ↑Thu Feb 25, 2021 10: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.)

mar wrote: ↑Thu Feb 25, 2021 11: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.

Mike Sherwin wrote: ↑Wed Feb 24, 2021 6:54 pmIn 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.