To SF team / Jim Ablett: SF 2.11 crash during first game...

[Martin Thoresen]

Thanks everyone for chiming in.

In any case...

There was a hardware problem making Naum - Spark stop so I have
decided to manually adjudicate that game as a draw.

Also, this problem might be the cause of the SF crash yesterday, so I have
resumed SF - Critter from the last position, the game just ended in a draw
by repetition.

The hardware issues should be resolved now, hopefully there won't be any
more trouble.

Ricardo, you are right that the CPU is overclocked and I am certainly not
denying that this could be a factor.

Best,
Martin

[rbarreira]

Ricardo, you are right that the CPU is overclocked and I am certainly not
denying that this could be a factor.

To be fair I did later notice that your page says you overclocked only to 4.2 GHz, which is just a little bit above its max turbo frequency of 3.6 GHz... so it might be a bit far-fetched to say the overclocking is to blame.

[bob]

Ricardo, you are right that the CPU is overclocked and I am certainly not
denying that this could be a factor.

To be fair I did later notice that your page says you overclocked only to 4.2 GHz, which is just a little bit above its max turbo frequency of 3.6 GHz... so it might be a bit far-fetched to say the overclocking is to blame.

I still believe, based on significant past experience, that this is "no man's land". It is _impossible_ to completely test a CPU at a new frequency to verify that it will work. The manufacturer has to study settling times, heat dissipation, thermal issues, etc, to decide where it can run safely. If you ramp up the clock, you need to do what in software engineering is called "complete path coverage" testing. You need to test every possible order of instructions, ways instructions can be paired, etc, to be certain that in every last case, there is enough settling time to get the right result of an instruction before it is latched.

Had a Ph.D. student here several years ago that slightly overclocked an AMD processor. Others had overclocked it significantly more. And everyone was running the usual reliability tests, including him, and it ran them all correctly. Yet on a molecular modelling program he worked on, it would crash after roughly 24 hours. While Intel ran it perfectly. He backed the clock off to the normal setting, and the program also ran perfectly on that box.

That convinced me that overclocking was not something I was going to try, when reliability/accuracy is an issue...

[Dann Corbit]

I got a severe crash analysing this position:
[d]3r1rk1/p1q2pbp/1np1p1p1/1p2P3/5P2/2N2Q1P/PPP3P1/3RRBK1 b - -

I had multi-pv set to 10, analysis set at 1 hour, 4 CPUs at 3 GHz, 64 bit operating system and 64 bit JA build engine, one GB hash.

The position is probably a bit more recognizable in this format:
3r1rk1/p1q2pbp/1np1p1p1/1p2P3/5P2/2N2Q1P/PPP3P1/3RRBK1 b - - bm Rxd1; c0 "positional scores are: Rxd1=10, f5=9, Na4=7, Nd5=5, a6=5, f6=4, g5=3"; id "tony.pos.06";

But I was analyzing the bare record under Arena.

The machine is not overclocked and routinely runs chess analysis over an entire weekend without incident. There is definitely a crash problem with the current stockfish.

[mhalstern]

Can you post the fire 1.31 personality.

Thanks

[Matt Weaver]

1) Fire 1.31 is stronger than Firebird 1.2

2) Both versions are stronger with custom settings than with the default settings

3) Fire 1.31 UCI options for setting piece values are most probably a bug - at least I noticed changing them does not affect anything. So very frequently it ends up playing with knight(s) against the bishop(s) (as other engines use to prefer bishops) and there's no way to change that. The other options work.

4) In Firebird 1.2 you must actually reduce the values for pieces to make them stronger. For example, after increasing the value for bishop from 325 to 350 the engine considers the bishop to be weaker than knight. Strange, but true.

5) Fire 1.31 needs very different settings for different time controls.

6) Time management of Fire 1.31 is not perfect. But at fixed time per move, and with custom settings, Fire 1.31 is stronger than Houdini 1.5 and Rybka 4.1, which means it's the best engine on Earth.

[kranium]

1) Fire 1.31 is stronger than Firebird 1.2

2) Both versions are stronger with custom settings than with the default settings

3) Fire 1.31 UCI options for setting piece values are most probably a bug - at least I noticed changing them does not affect anything. So very frequently it ends up playing with knight(s) against the bishop(s) (as other engines use to prefer bishops) and there's no way to change that. The other options work.

4) In Firebird 1.2 you must actually reduce the values for pieces to make them stronger. For example, after increasing the value for bishop from 325 to 350 the engine considers the bishop to be weaker than knight. Strange, but true.

5) Fire 1.31 needs very different settings for different time controls.

6) Time management of Fire 1.31 is not perfect. But at fixed time per move, and with custom settings, Fire 1.31 is stronger than Houdini 1.5 and Rybka 4.1, which means it's the best engine on Earth.

Thanks Matt-

My bad...
I just checked and found that I simply failed to call InitMaterialValue() after a UCI (or fire.cfg) piece value change.

This has now been corrected in the 1.32 source code....
which I am uploading to Chesslogik.com.

I don't have a 64-bit system, so I've compiled and posted only a 32-bit version.
Will post a 64-bit compile as soon as someone creates it for me.

I also changed the default piece values as follows:
Knight 325
Bishop 325
to
Knight 320
Bishop 330

in an effort to make Fire play in a more typical manner concerning knight/bishops.

Many thanks for your detailed investigation and report.
Norm

[Matt Weaver]

Great news, Norm!

Also looking forward to 64-bit version when it becomes available.

Thanks for the wonderful engine.