Jumbo 0.5.3 - Birth of the Jumbo Twins

[Sven]

I have released Jumbo 0.5.3 with four different binaries. Jumbo now supports two different board representations: classical mailbox and bitboards. Both are built from the same source tree, just with a different compile switch. And for both variants there are still a 32-bit and a 64-bit binary.

Homepage of Jumbo Twins

For testing I recommend to use the 64-bit bitboard binary, of course, even though (or maybe: because) there might still be some bugs around.

[Graham Banks]

Always good to see a new Jumbo!

[hgm]

I suppose that with 'classical mailbox' you mean a program that must scan over the board for slider moves to see where these end, and thus cannot really selectively generate captures without effectively passing through all non-captures, and cannot do staged generation of non-captures in MVV order?

Are you also planning to make an 'advanced mailbox' version that can do these things, based on incrementally updated view distances and attack maps?

[Sven]

I suppose that with 'classical mailbox' you mean a program that must scan over the board for slider moves to see where these end, and thus cannot really selectively generate captures without effectively passing through all non-captures, and cannot do staged generation of non-captures in MVV order?

Yes. Any bad thing you can imagine. Simply Jumbo as you already know it

Are you also planning to make an 'advanced mailbox' version that can do these things, based on incrementally updated view distances and attack maps?

No. I'll leave that up to you

[tttony]

Cool!

I just ran both engines in Arena 3.0 in startpos the BB it's like 250kns+ than mailbox

There was quite of work there, changing everything to bb and debugging like hell

[Stan Arts]

I suppose that with 'classical mailbox' you mean a program that must scan over the board for slider moves to see where these end, and thus cannot really selectively generate captures without effectively passing through all non-captures, and cannot do staged generation of non-captures in MVV order?

Are you also planning to make an 'advanced mailbox' version that can do these things, based on incrementally updated view distances and attack maps?

Speaking purely speed, wouldn't updating view distances and attack maps negate any speed gain you might get from staged generation?
Though you could find more uses for such tables ofcourse.

But move generation tends to be pretty fast anyway even in a classical mailbox.

In Nemeton (16x12 mailbox) I have a separate capture generator that does have to scan slider paths but doesn't have to store quiet moves in between so is considerably faster than the normal generator.

[hgm]

Updating the view distances and attack maps is quite cheap, as they contain the information you need to do it efficiently. E.g. if you evacuate a square, all you have to do for the view distance is for the four rays passing through it add the up-stream and down-stream distance, and write that in the up-stream and down-stream views in your direction. For the attack map you just have to mask out the bits for slider attacks to the evacuated square, and (if there are any...) displace these to the new target downstream.

Slider mobility per piece can come as a nearly free side effect of the view-distance update. But the most important thing is that you can delay updates until you really need them. You can split MakeMove in a key update, a board + view-distance update and an attack-map update. You would only do the board update if there was no repeat or hash hit. This should allow you to do the evaluation, including mobility. Oly when this does not produce a stand-pat cutoff, you would have to update the attack map, before searching any moves. If the existing attack map doesn't attack ay non-futile victim, you can make a quick check whether the previous (opponent) ply gave you a better target (this happes only through moving soft-pinned pieces), and if that is not the case you can fail low before updating the attack map for the opponent's new attacks, (and removing your attacks with the piece he captured, or which he blocked).

Even without using such a delayed update, the view-distance work extremely well in my Tenjiku-Shogi engine. My main competitor is a bitboard engine, and it does 4.5 knps. My mailbox/view-distance engine does 450 knps on similar positions.

[Jamal Bubker]

Thanks Sven

[gerold]

Many thanks Sven.

[Daniel Anulliero]

Thanks for the new Jumbo Sven