I am looking for two test positions (1 fail high, 1 fail low) for longer thinking times, something like 1 to 10 minutes. Want to test different hash sizes (e.g. 1 GB vs, 2 GB) and hyperthreading performance. If the solution is found too quickly, like in many Eigenmann tests, then it is more difficult to establish any performance differences.

You will also need to consider the impact of multiple threads. Because of multi-thread variability it may be necessary to run each individual position 100 times to get an average of the solving time. You may be shocked to see the time range from fastest to slowest solving time. If the engine is determinate just one pass is required for single core. By the time 16 cores are used the hash size may not have so much of an impact and milti-thread variation may reduce, however I have not carried out any tests with Stockfish for some time.

I did make a recent post on hash effect for single thread here

http://rybkaforum.net/cgi-bin/rybkaforum/topic_show.pl?tid=32213

that may not be the results you would have predicted. If you run a search on "position solving" or say "Hash effect" you may find some previous discussions here.

PeterG

I did make a recent post on hash effect for single thread here

http://rybkaforum.net/cgi-bin/rybkaforum/topic_show.pl?tid=32213

that may not be the results you would have predicted. If you run a search on "position solving" or say "Hash effect" you may find some previous discussions here.

PeterG

All of these are solved in a minute or two by strong engines on decent hardware.

2q2r2/3n1p2/p2p2k1/3PpRp1/P1n1P3/2P2QB1/1rB1R1P1/6K1 w - - acd 25; bm Rxg5+; c3 "Rxg5+"; ce 32744; dm 12; id "Arasan16.003"; pm Rxg5+;

pv Rxg5+ Kxg5 Qf5+ Kh6 Bf4+ exf4 g4 Rb1+ Bxb1 Qc5+ Kh1 Qg1+ Kxg1 Nce5 Rh2+ Kg7 Qh7+ Kf6 Qh4+ Kg7 Qh6+ Kg8 Qh8#; n1QBq1k1/5p1p/5KP1/p7/8/8/8/8 w - - acd 25; bm Bc7; c0 "

CCC post"; c1 "diff=9"; c2 "#12; 00:00 @ C0/R7/K3/P0/X35;"; c3 "Bc7"; ce 32744; dm 12; id "ZPTS.06"; pm Bc7; pv Bc7 Qxc8 gxf7+ Kh8 Be5 Qc5 Bb2 Nc7 Ba1 a4 Bb2 a3 Ba1 a2 Bb2 a1=R Bxa1 Qd4+ Bxd4 Nd5+ Ke6+ Nf6 Bxf6+; r7/1QP1N1Kp/pn2P1b1/Nnk2p2/7p/p4BP1/1rPPp2q/8 w - - acd 27;

bm Nd5 Qxa8; ce 32742; dm 13; pm Nd5; pv Nd5 Nd4 Qxa8 Nc8 Qxc8 Be8 Qxe8 Qxg3+ Kh8 Qe5+ Kxh7 Qxc7+ Nxc7 Rb6 Qe7+ Rd6 Nb7+ Kb6 Qxd6+ Ka7 Qxd4+ Kb8 Nxa6+ Kc8 Qd7+; c0 "Qxa8 also wins, but Nd5 wins much faster.";8/8/7K/8/p1p5/2Bp4/pn1N4/k3N3 w - - acd 27; bm Nxd3; c0 "

level: hard-16"; c1 "28) Se1xd3 gewinnt"; c3 "Nxd3"; ce 32742; dm 13; id "EG 2175"; pm Nxd3; pv Nxd3 cxd3 Bh8 a3 Kg7 Nd1 Kg6+ Nb2 Kf6 Na4 Kf5+ Nb2 Ke5 Na4 Kd5+ Nb2 Kd4;
Interesting positions with positions 2 to 4 being the more difficult. In fact I could not find an engine that solved position 2 although I am only using 5 man Syzgy bases. asmFish failed to solve by the time it hit 61 ply and as far as I could see, engines were spending no time looking at the key move with, in most cases, instant dismissal of giving up the Queen. Strangely, if I played 1.Bc7, all engines instantly output the mate sequence thus it would seem the early dismissal of the Queen sac prevents them from seeing the correct move.

All engines I tested chose 1.gxh7+

[Event "user923005"]

[Site "?"]

[Date "????.??.??"]

[Round "?"]

[White "?"]

[Black "?"]

[Result "*"]

[Annotator "Grayson,Peter"]

[SetUp "1"]

[FEN "n1QBq1k1/5p1p/5KP1/p7/8/8/8/8 w - - 0 1"]

[PlyCount "1"]

1. Bc7 ({asmfishw_2017-07-10_popcnt:} 1. gxh7+ Kh8 2. Qxa8 Qe6+ 3. Kg5 Kxh7 4.

Kf4 a4 5. Qa5 Qd6+ 6. Ke4 Qg6+ 7. Kd4 Qd6+ 8. Ke4 {[%eval 0,61]}) ({Komodo 11.

2 64-bit:} 1. gxh7+ Kh8 2. Qxa8 Qe6+ 3. Kg5 Kxh7 4. Bxa5 Qe3+ 5. Kg4 Qg1+ 6.

Kh3 Qf1+ 7. Kh2 Qe2+ 8. Kg1 Qd1+ 9. Kf2 Qc2+ 10. Kf3 Qd3+ 11. Kf4 Qd4+ 12. Qe4+

Qxe4+ 13. Kxe4 Kg6 14. Kd5 f5 15. Bd2 f4 16. Bxf4 Kf5 17. Bd2 Kg6 18. Bc3 Kf7

19. Kc5 Ke6 20. Kb4 Kf7 21. Bd2 Ke6 22. Kb3 Kd5 23. Bc3 Ke4 24. Bb4 {[%eval 1,

34]}) ({Houdini 5.01 Pro x64-popc:} 1. gxh7+ Kh8 2. Qxa8 Qe6+ 3. Kg5 Qe5+ 4.

Kh4 Qf4+ 5. Kh3 Qe3+ 6. Kg2 Qe2+ 7. Kg3 Qe3+ 8. Kg2 {[%eval 0,36]}) ({Deep

Rybka 4.1 SSE42 x64:} 1. gxh7+ Kh8 2. Qxa8 Qe6+ 3. Kg5 Kxh7 4. Qxa5 f6+ 5. Kf4

Qc4+ 6. Kf5 Qc8+ 7. Kxf6 Qc6+ 8. Ke5 Qe8+ 9. Kf4 Qf7+ 10. Ke3 {[%eval 0,32]}) (

{Deep HIARCS 14 WCSC:} 1. gxh7+ Kh8 2. Qxa8 Qe6+ 3. Kg5 Kxh7 4. Qxa5 Qe3+ 5.

Kg4 f5+ 6. Kxf5 {[%eval 3,33]}) *

Position 3 gave two different scenarios when older engines using Nalimov EGTB's were significantly faster finding the solution than today's more modern engines but when tested on my overclocked quad but that quickly changed when I ran today's engines on the dual Xeon machine.

All engines I tested chose 1.gxh7+

[Event "user923005"]

[Site "?"]

[Date "????.??.??"]

[Round "?"]

[White "?"]

[Black "?"]

[Result "*"]

[Annotator "Grayson,Peter"]

[SetUp "1"]

[FEN "n1QBq1k1/5p1p/5KP1/p7/8/8/8/8 w - - 0 1"]

[PlyCount "1"]

1. Bc7 ({asmfishw_2017-07-10_popcnt:} 1. gxh7+ Kh8 2. Qxa8 Qe6+ 3. Kg5 Kxh7 4.

Kf4 a4 5. Qa5 Qd6+ 6. Ke4 Qg6+ 7. Kd4 Qd6+ 8. Ke4 {[%eval 0,61]}) ({Komodo 11.

2 64-bit:} 1. gxh7+ Kh8 2. Qxa8 Qe6+ 3. Kg5 Kxh7 4. Bxa5 Qe3+ 5. Kg4 Qg1+ 6.

Kh3 Qf1+ 7. Kh2 Qe2+ 8. Kg1 Qd1+ 9. Kf2 Qc2+ 10. Kf3 Qd3+ 11. Kf4 Qd4+ 12. Qe4+

Qxe4+ 13. Kxe4 Kg6 14. Kd5 f5 15. Bd2 f4 16. Bxf4 Kf5 17. Bd2 Kg6 18. Bc3 Kf7

19. Kc5 Ke6 20. Kb4 Kf7 21. Bd2 Ke6 22. Kb3 Kd5 23. Bc3 Ke4 24. Bb4 {[%eval 1,

34]}) ({Houdini 5.01 Pro x64-popc:} 1. gxh7+ Kh8 2. Qxa8 Qe6+ 3. Kg5 Qe5+ 4.

Kh4 Qf4+ 5. Kh3 Qe3+ 6. Kg2 Qe2+ 7. Kg3 Qe3+ 8. Kg2 {[%eval 0,36]}) ({Deep

Rybka 4.1 SSE42 x64:} 1. gxh7+ Kh8 2. Qxa8 Qe6+ 3. Kg5 Kxh7 4. Qxa5 f6+ 5. Kf4

Qc4+ 6. Kf5 Qc8+ 7. Kxf6 Qc6+ 8. Ke5 Qe8+ 9. Kf4 Qf7+ 10. Ke3 {[%eval 0,32]}) (

{Deep HIARCS 14 WCSC:} 1. gxh7+ Kh8 2. Qxa8 Qe6+ 3. Kg5 Kxh7 4. Qxa5 Qe3+ 5.

Kg4 f5+ 6. Kxf5 {[%eval 3,33]}) *

Position 3 gave two different scenarios when older engines using Nalimov EGTB's were significantly faster finding the solution than today's more modern engines but when tested on my overclocked quad but that quickly changed when I ran today's engines on the dual Xeon machine.

I have 6 man tablebase files on all my machines (on SSD drives).

The second problem is from problem set ZPTS, which is a null move problem set, if I recall correctly.

So probably engines like Matefinder or engines which do a null move verification step will fare better.

The second problem is from problem set ZPTS, which is a null move problem set, if I recall correctly.

So probably engines like Matefinder or engines which do a null move verification step will fare better.

Attachment: zpts.epd - zpts problem set (2k)

Thanks for the zpts.epd. I'll have a look through those.

Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill