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.
Jumbo 0.5.3 - Birth of the Jumbo Twins
Moderators: hgm, Rebel, chrisw
-
- Posts: 4052
- Joined: Thu May 15, 2008 9:57 pm
- Location: Berlin, Germany
- Full name: Sven Schüle
-
- Posts: 41461
- Joined: Sun Feb 26, 2006 10:52 am
- Location: Auckland, NZ
-
- Posts: 27809
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: Jumbo 0.5.3 - Birth of the Jumbo Twins
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?
Are you also planning to make an 'advanced mailbox' version that can do these things, based on incrementally updated view distances and attack maps?
-
- Posts: 4052
- Joined: Thu May 15, 2008 9:57 pm
- Location: Berlin, Germany
- Full name: Sven Schüle
Re: Jumbo 0.5.3 - Birth of the Jumbo Twins
Yes. Any bad thing you can imagine. Simply Jumbo as you already know ithgm wrote: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?
No. I'll leave that up to youhgm wrote:Are you also planning to make an 'advanced mailbox' version that can do these things, based on incrementally updated view distances and attack maps?
-
- Posts: 268
- Joined: Sun Apr 24, 2011 12:33 am
Re: Jumbo 0.5.3 - Birth of the Jumbo Twins
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
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
Skiull http://skiull.blogspot.com
-
- Posts: 179
- Joined: Fri Feb 14, 2014 10:53 pm
- Location: the Netherlands
Re: Jumbo 0.5.3 - Birth of the Jumbo Twins
Speaking purely speed, wouldn't updating view distances and attack maps negate any speed gain you might get from staged generation?hgm wrote: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?
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.
-
- Posts: 27809
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: Jumbo 0.5.3 - Birth of the Jumbo Twins
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.
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.
-
- Posts: 326
- Joined: Mon May 24, 2010 4:32 pm
Re: Jumbo 0.5.3 - Birth of the Jumbo Twins
Thanks Sven
-
- Posts: 10121
- Joined: Thu Mar 09, 2006 12:57 am
- Location: van buren,missouri
Re: Jumbo 0.5.3 - Birth of the Jumbo Twins
Many thanks Sven.
-
- Posts: 759
- Joined: Fri Jan 04, 2013 4:55 pm
- Location: Nice