Komodo 11.2.2 - Initial position until depth 54

[zullil]

Of course, the burning question is,
"Does Larry like the QGD Slav?"

I was expecting "What is the point of this exercise?"

Maybe to make ones room a bit warmer during this cold season.

Joking aside, I think you are correct regarding the type modifier.
unsigned long or unsigned int could be more correct, but would still
overflow since 4,294,967,295 is still not enough for 6.715.834.390 as shown above.

I was also wondering why the times for the last three iterations are identical.

I am just a hobbyist and not an expert programmer but it seems the last 3 clocks shows an overflow.

Code: Select all

52   2.407.848.925   27:20:50:49    5.878.695.730.832   1.16   23   2.441.472   996 
53   3.503.914.914   40:13:18:35    8.592.468.339.137   1.46   26   2.452.248   996 
54   6.715.834.390   77:17:30:34   16.530.039.123.273   1.92   19   2.461.353   996

2,407,848,925 is already above 'signed int' according to the table found here: https://msdn.microsoft.com/en-us/library/296az74e.aspx

Sure, but I was referring to the times shown in the actual output from the engine for depth 52-54. Overflow or not, why are the times the same for all three iterations?

[MikeGL]

Of course, the burning question is,
"Does Larry like the QGD Slav?"

I was expecting "What is the point of this exercise?"

Maybe to make ones room a bit warmer during this cold season.

Joking aside, I think you are correct regarding the type modifier.
unsigned long or unsigned int could be more correct, but would still
overflow since 4,294,967,295 is still not enough for 6.715.834.390 as shown above.

I was also wondering why the times for the last three iterations are identical.

I am just a hobbyist and not an expert programmer but it seems the last 3 clocks shows an overflow.

Code: Select all

52   2.407.848.925   27:20:50:49    5.878.695.730.832   1.16   23   2.441.472   996 
53   3.503.914.914   40:13:18:35    8.592.468.339.137   1.46   26   2.452.248   996 
54   6.715.834.390   77:17:30:34   16.530.039.123.273   1.92   19   2.461.353   996

2,407,848,925 is already above 'signed int' according to the table found here: https://msdn.microsoft.com/en-us/library/296az74e.aspx

Sure, but I was referring to the times shown in the actual output from the engine for depth 52-54. Overflow or not, why are the times the same for all three iterations?

Since we don't have the source, I think we can only speculate.
Maybe the 4 byte wide variable is not enough to store that overflown
value, hence it keeps on showing the same negative value. But I get your
point, it should at least increment that negative value also and not display
the same one repeatedly. Probably just a printf specific or compiler
implementation on how to handle an overflow.

edit:

[fastgm]

wow 2 months but is 2GB hash enough?

The machine had only 4 GB RAM.
But it would be interesting to know if a larger hash size is faster and if, how much.

[Dann Corbit]

What is wanted here is unsigned long long.
It can hold up to 18446744073709551615 on most systems (assuming 8 byte two's complement).

[Dann Corbit]

Of course, the burning question is,
"Does Larry like the QGD Slav?"

I was expecting "What is the point of this exercise?"

I am astounded that people do not find it interesting.
I would like to see the answer out to 100 ply.
But I am not that patient.

[mjlef]

Komodo 11.2.2 64-bit - 2 threads - 2048 MB Hash - Initial position

Code: Select all

info depth 52 time -2147483648 nodes 5878695730832 score cp 23 nps 2441472 hashfull 996 tbhits 0 pv d2d4 e7e6 c2c4 d7d5 b1c3 g8f6 g1f3 a7a6 c4d5 e6d5 c1g5 c8e6 e2e3 b8d7 f1d3 h7h6 g5f4 c7c5 d4c5 d7c5 d3c2 f8e7 f3d4 e8g8 e1g1 a8c8 a1c1 e7d6 c3e2 d8e7 d4f5 e6f5 c2f5 c5e6 f4g3 d6g3 h2g3 e7b4 e2f4 c8c1 d1c1 e6f4 g3f4 g7g6 f5d3 g8g7 f1d1 d5d4 e3e4 f8d8 a2a3 b4b6 b2b4 d8e8 e4e5 f6d5
info depth 53 time -2147483648 nodes 8592468339137 score cp 26 nps 2452248 hashfull 996 tbhits 0 pv d2d4 e7e6 c2c4 d7d5 b1c3 g8f6 g1f3 f8b4 c1g5 h7h6 g5f6 d8f6 e2e3 c7c5 a1c1 d5c4 f1c4 c5d4 f3d4 b4c3 c1c3 e8g8 d1f3 f6f3 d4f3 b8c6 e1e2 c8d7 a2a3 a8c8 h1c1 a7a6 c4d3 f7f5 f3d2 f8d8 d2b3 c6e5 c3c8 d7c8 d3b1 c8d7 b3d4 e5c6 b1a2 c6d4 e3d4 d7b5 e2e3 g8f7 c1c7 d8d7 c7d7 b5d7 d4d5 e6e5 d5d6 f7f6 a2d5 b7b6 d5c4 a6a5 c4d5
info depth 54 time -2147483648 nodes 16530039123273 score cp 19 nps 2461353 hashfull 996 tbhits 0 pv d2d4 g8f6 c2c4 c7c6 b1c3 d7d5 c4d5 c6d5 g1f3 b8c6 c1f4 c8f5 d1b3 c6a5 b3a4 f5d7 a4c2 e7e6 e2e3 f8e7 f1d3 a5c6 a2a3 f6h5 f4g3 f7f5 e1g1 e8g8 a1c1 h5g3 h2g3 a8c8 b2b4 a7a5 b4b5 c6b4 a3b4 a5b4 c2b2 b4c3 c1c3 c8c3 b2c3 e7d6 c3a1 d8a8 f3e5 d6e5 d4e5 a8a1 f1a1 f8c8 a1a7 c8c1 g1h2 d7c8 g3g4 f5g4 h2g3 c1c3 a7a8 d5d4 g3g4

.

Looks like the variable for time is of the wrong integer type.

I will have to upgrade to 64 bit instead of 32 for these extra long runs. Komodo actually uses floating point for time internally, so this is an easy change. The again I wonder what the GUIs will do with these super long times. If they are using 32 bit ints, I have no idea how they will react.

[syzygy]

Looks like the variable for time is of the wrong integer type.

Fixed

[zullil]

Looks like the variable for time is of the wrong integer type.

Fixed

Thanks, Ronald.

Now I can give Cfish 20 threads and 32 GB of hash and let it search startpos for months on end. Heating my house with natural gas is more efficient, but electricity is rather inexpensive here as well.