Worst advice

[Henk]

For a chess engine worst advice you may get is probably improving low level efficiency of your software.

[hgm]

Wouldn't making the engine SMP also count as such?

[Henk]

Don't know how manageable the solution will be. Winning a factor 5 in speed is seductive.

My attempt to improve the speed few weeks ago is bad for current structure of my code.

[hgm]

I think you should decide in advance whether you want to have a very fast program, and if so, design it to be fast from scratch. And for your first program this would be a very bad choice. First you should master extensions/reductions, pruning and move ordering to make a strong engine. Then you can do a re-write to change to a fast implementation.

[Henk]

I think probably last steps are improve lowest level efficiency, tune and stop development. So if you don't want to stop developing your current source don't follow that track.

[bob]

For a chess engine worst advice you may get is probably improving low level efficiency of your software.

A slow program that handles pruning correctly (null-move, LMR, LMP, Futility, and such) will be FAR stronger than an optimized program that doesn't use any of the tree-size-reduction algorithms that are well-known.

First, it needs to be correct.

Second, it needs to be complete.

Then and only then does it need to be fast...

[hgm]

True, but that is order of importance, which doesn't necessarily coincide with temporal order. If you start with a slow design that uses crummy algorithms, you might have painted yourself in a corner by the time you get to the speed part, and need to rewrite so much that you might as well start over again.

[bob]

True, but that is order of importance, which doesn't necessarily coincide with temporal order. If you start with a slow design that uses crummy algorithms, you might have painted yourself in a corner by the time you get to the speed part, and need to rewrite so much that you might as well start over again.

I was thinking more about Henk. Lots of bugs, apparently few pruning methods used giving very shallow searches, etc... All that needs to be handled first. In your context it is a bit of chicken and egg, as obviously you don't want a correct but lousy design either... But optimizing something that is badly broken is a waste also.

[jdart]

Non-broken is actually the top priority. I learned this the hard way. You need to make sure every piece of code does what you think it should do, and you need to have a good understanding of what it should do.

--Jon

[bob]

Non-broken is actually the top priority. I learned this the hard way. You need to make sure every piece of code does what you think it should do, and you need to have a good understanding of what it should do.

--Jon

If you were only as old as I am, and had attended as many ACM computer chess events as I have, and had seen all of the silly failures over the years (pawn to 8th rank without promotion, unable to castle, refusal to handle opponent's under promotion, announcing a target time limit that is 10x longer than the remaining time on the clock, and in my case, using singular extensions to extend beyond my max depth of PV limit in 1994 even)

ICS/ICC/FICS/etc were the first step. We could play hundreds of games in a short time, and show up at tournaments with programs that did not do silly things or crash. But it took weeks. Cluster testing shortened this to a day. I can safely make a change today, and enter a tournament tomorrow knowing there are no serious bugs present.

Everyone forgets the "correct" before "clever" idea. Something that is clever (or fast) but broken is not going to help much.

Of course, back then, I can remember when Cray Blitz went parallel in 1983 when the prototype of the XMP was made available less than a month prior to the 1983 WCCC. We entered that event and when round 1 started, that was our FIRST full game. All we had time to do prior to that was run a few test positions. Harry was in Mendota Heights the day before the tournament helping Cray track down a parallel processing bug in their parallel programming library. And somehow, that year, no crashes, no nothing, which surprised all of us based on past experiences with untested code.