Potentially Trapped Pieces

[CRoberson]

I'm assuming no null-move search yet? That's about the only reason I could think of where a 7 ply search would take that long...

If only it were that simple. Null move is implemented. Without null move it takes 73 seconds. <sigh>

jm

My engine is nowhere near as fast as crafty but still finds a5 on ply 7 in just a few seconds. Do you have move ordering at all? It makes an enormous difference

Yep, move ordering is there: PV moves, then hash moves, captures (MVV/LVA) and checks. Killer moves and history heuristic are there also.

But this did give me an idea which I am looking into. Currently, I am only sorting the move scores for the first handful of moves (depending on the total number of moves), and not bothering to sort the rest. This did slow some positions down (primarily positions that fail low, of course) but gave me an overall improvement for general gameplay due to the speed increase.

Hmmmm.....

jm

Telepath found it in 7 ply and searched 898,513 nodes compared
to your 19.6 million nodes. Given that you have Null move working,
maybe you have a bug in transposition tables. Also, are you using
LMR?

Your move ordering is different from mine. I don't use hashmoves
or checks. Could you possibly be ordering some of the history
moves before the killers?

Yes, I am using LMR.

Turning off hash tables takes 90 seconds and just over 30 million nodes.

Here are the hash stats upon reaching the correct answer:
Hash Saves = 894539
Failed Saves (stale data) = 150425
Hash Probes = 5117049
Hash Hits = 351165
Hash Returns = 89798
Hash Zeroes (probes of positions with no hash data) = 4562136

I have no idea if this is remotely decent performance or not.

And, no, history moves (with no other modifiers) will never be scored higher than a killer move.

jm

Ok, try turning off all extensions. See if that makes a difference.
If it does, then turn them on one by one and see where the culprit
is.

[JVMerlino]

Ok, try turning off all extensions. See if that makes a difference.
If it does, then turn them on one by one and see where the culprit
is.

Well, turning off "all" extensions is pretty easy, since I only have two. Singular reply and check. Turning off those does shorten the time from 54 seconds to 24. I also have a cap on the extension depth, which is currently set at 5 plies. Finally, LMR will reduce the extension depth.

So, of course, it is the check extension that is the culprit. But I would assume that turning it off would make overall gameplay worse, wouldn't it? I'll do some tests overnight, but I'm not encouraged....

jm

[sje]

With the right bitboards it's not too difficult to detect trapped pieces.

Consider:

Code: Select all

  // atkfs = attacks from a square
  // locbc = locus by color
  // atkbc = attacks by color
  // good = the side on the move
  // evil = the side not on the move

  const BB crampbb = (atkfs[sq] - locbc[good]) - atkbc[evil];

If the cramp bitboard is empty, it means that the piece on the square sq has nowhere safe to go, unless there is a safe capture. The safe capture status needs a little more calculation including pinned/frozen bitboards for an accurate result. Wilkins' program Paradise did this (using lists, not bitboards) in its primitive production called "MOBIL" and the result was heavily used in other productions.