When testing HIARCS 13.2 SP (No position learn) through the Richter test set with a range of hash values, something unexpected happened. It gave a range of average solving times of best at 1.45s with 16 Mb hash to worst at 11.94s with 2Gb hash. Most of the positions can be solved quickly so I expected that a small time increase for higher hash values would be obtained.
There were some minor oddities but the main cause of this time variation was the single position No.3 where the engine solving ply depth ranged from 3.69s,13 ply with 16 Mb (best), to 130.25s, 18 ply with 1Gb (worst).
Pos 3
'HIARCS 13.2 SP-64MB GUI11/DEVO4' 114.77s / 18,
'HIARCS 13.2 SP-32MB/DEVO4' 87.47s / 17,
'HIARCS 13.2 SP-16MB/DEVO4' 3.69s / 13 BEST,
'HIARCS 13.2 SP-8MB/DEVO4' 7.16s / 14,
'HIARCS 13.2 SP-96MB/DEVO4' 86.39s / 18,
'HIARCS 13.2 SP-128MB/DEVO4' 84.50s / 18,
'HIARCS 13.2 SP-192MB/DEVO4' 105.45s / 18,
'HIARCS 13.2 SP-256MB/DEVO4' 103.56s / 18,
'HIARCS 13.2 SP-512MB/DEVO4' 53.38s / 17,
'HIARCS 13.2 SP-1024MB/DEVO4' 130.25s / 18,
'HIARCS 13.2 SP-2048MB/DEVO4' 128.44s / 18,
'HIARCS 13.2 MP 1T-16MB/DEVO4' 3.75s / 13
So the question then is, "why such ply-depth and time to solve variation in this position?". Would anyone else would care to run the 14 test positions with varying hash in same or different GUI to see if this is peculiar to my set up?
PeterG
Test conditions:
GUI Deep Fritz 11 GUI 11, 03.06.2009 update.
Using function Analysis/Process Test set
PC: Q9550 with 4Gb RAM, standard clock, XP Home Ed.
"HIARCS 13.2 SP NL" engine created with parameter position learn unchecked.
GUI closed down and reopened before each run to ensure no residual hash.
Richter.epd
2k4r/pp3ppp/2p2n2/5PBb/P3P3/2Nr3P/1PB2bP1/R3R2K b - - bm Rxh3+;
rn2kb1r/p3qppp/2p2n2/1p2p1B1/2B1P3/1QN5/PPP2PPP/R3K2R w KQkq - bm Nxb5;
r3rnk1/pbq1b1pp/1pp1pp2/4N3/2PP2Q1/3B4/PP1B1PPP/R3R1K1 w - - bm Bxh7+;
3r2rk/2q2p1p/p2p1pn1/1p1PnN1Q/2p1P3/2P3B1/PPBN2K1/R7 w - - bm Qxh7+;
r4rk1/1R3p1p/p3pBpP/qb1pP3/2nP4/P2Q1N2/5PP1/2R3K1 w - - bm Qxg6+;
q5rr/1b2b1k1/pp2p1p1/2p1PpP1/2P2P1R/2BB3R/PP5Q/4K3 w - - bm Bxf5;
r6r/p2Rbk1p/2p2p2/q6b/8/2N2N1P/P1PP1PP1/2BQ2K1 w - - bm Nd5;
2r2rk1/1p1bbppp/p2ppn2/q7/4PP2/2N1BB2/PPP3PP/R3QR1K w - - bm Nd5;
rn1q1r2/pb3pk1/4p1p1/4P1P1/1ppP1N2/8/PPB2PP1/R2QK2R w KQ - bm Rh7+;
r4k1r/ppp3pp/2n1bp2/7B/q3PB2/2Q5/PP1R1PPP/2KR4 w - - bm Rd7;
r1bn1rk1/5p1p/1qp2p1Q/ppb1pP2/3pP2N/P1NP2P1/BPP1K2P/R4R2 w - - bm Na4;
r1b1r1k1/1p1n1p1p/2ppnqp1/8/p1P1P3/5P2/PbNQNBPP/1R2RBK1 w - - bm Rxb2;
r1bqnrk1/pp1pppbp/6p1/n3P3/3N4/1BN1B3/PPP2PPP/R2QK2R w KQ - bm Bxf7+;
1k6/p7/1p3P2/3QP3/8/4q3/6PP/2r2R1K w - - bm Qf3;
Impact of hash on HIARCS 13.2 position solving
Moderators: Harvey Williamson, Steve B, Watchman
Forum rules
This textbox is used to restore diagrams posted with the fen tag before the upgrade.
This textbox is used to restore diagrams posted with the fen tag before the upgrade.
-
Peter Grayson
- Member
- Posts: 208
- Joined: Sat Aug 04, 2007 3:23 pm
- Location: South Wales, UK
-
Peter Grayson
- Member
- Posts: 208
- Joined: Sat Aug 04, 2007 3:23 pm
- Location: South Wales, UK
Hi Larry,Larry wrote:Hi Peter, I see you put in quite a bit of work on this, with zero response.
Scroll up a bit and you see I did the same, but with a dedicated machine,
with the same response. It seems RAM is not an interesting topic on this
forum. Don't be discouraged...
RAMbo sends his regards...
Well I've always found the influence of RAM on an engine's solving capability to be interesting. Certainly with today's engines the general thought that more hash is best does not necessarily work out in practice for position solving.
Whether the position solving performance transitions into actual game play is doubtful because there is unlikely to be the situation of a single best move for each position encountered during game play. Also when position solving, hash starts off empty but in game play there may already be significant information in hash that influences evaluation and move selection. Even more complex when multi-threads in use.
Best regards,
Peter