Improving speed

[Henk]

What I understood is that there are engines that are five times faster than Fairy-max. That means I should be able to get 3.5 million NPS. I already demolished my code to get a speed of 1.4 million NPS on my machine. So there is still room for improvement. Factor two would be nice.

[AlvaroBegue]

Use a profiler to see where the time is going.

One key thing to keep your program fast is avoiding dynamic memory allocation. You don't need it at all.

[Sven]

What I understood is that there are engines that are five times faster than Fairy-max. That means I should be able to get 3.5 million NPS. I already demolished my code to get a speed of 1.4 million NPS on my machine. So there is still room for improvement. Factor two would be nice.

Your goal must be to reach a rating above 2200. If I assume a current rating for Skipper in the range of 1700-1800 (just a wild guess) then you can't reach that goal only by making your engine faster. "Factor two" would be about +70 .. +100 Elo points for you, I would consider all energy as wasted that you put into improving speed at that stage of the engine. So you need to improve your search and eval, and this starts at fixing (a lot of) bugs and nowhere else.

In the game Jumbo vs. Skipper on last Sunday at the HGM online blitz tourney, Skipper played 8...a5 after 6...a6 and 7...b6, that *is* a bug (probably in the eval) and you have to fix it. In move 25 Skipper played Rxa2?? which loses the rook (or queen vs rook, as in the game) in very few plies (after Re1 Qd5 Qb3 the rook has no safe square). A program must see a simple loss of material in five plies, even in blitz. *That* is where you need to investigate first, not NPS, LMR, mating the bare king or WTF

[Dann Corbit]

First make it right, then make it fast.

"The only way to write complex software that won't fall on its face is to hold its global complexity down - to build it out of simple pieces connected by well-defined interfaces, so that most problems are local and you can have some hope of fixing or optimizing a part without breaking the whole" - Eric S. Raymond, The Art of Unix Programming

"As compelling as it is to try to make things go faster, remember that optimization should usually be the last stage of the development process, and generally should be subordinate to other software goals.... The worst time to optimize is the instant you start writing code.... the most premature optimization is the one you do without using a profiler or other measurement tool first" - Michael Lee, C Unleashed

[AlvaroBegue]

Dann's quotes are nice and all, but they seem to imply that you need to choose between speed and clarity. Clarity is certainly more important, but the vast majority of the time you can write clear code that is reasonably fast from the beginning. Most of the things you can do that would slow down a chess program by a factor of several are probably just really really bad ideas.

[Dann Corbit]

Dann's quotes are nice and all, but they seem to imply that you need to choose between speed and clarity. Clarity is certainly more important, but the vast majority of the time you can write clear code that is reasonably fast from the beginning. Most of the things you can do that would slow down a chess program by a factor of several are probably just really really bad ideas.

The focus of the quotes was simple:
1. Write clear, simple code.
2. Debug the fully functional code.

Then, if the program does not meet specifications profile it.
Then, if the profile reveals hot spots, optimize it.

Yes, you should write code that is fast from the beginning. This is always related to correct choice of algorithms (*).

If you use a linked list when you should have used a hash table, there will be a severe penalty to pay.

In relation to this, the best way to optimize is to choose a better algorithm for the hot spot when possible.

Tweaky, fiddly things like inline assembly should be a last resort.

(*) Admittedly, you can write something that is super-slow simply through talented use of mind-blowing stupidity like allocating and freeing every variable in your program.

[lauriet]

I can agree with the advice about bug free code.
I rewrote my first program with the knowledge gained, and the second version was magically about 5 times faster. A combination of better algorithms and less bugs.

[Dann Corbit]

I can agree with the advice about bug free code.
I rewrote my first program with the knowledge gained, and the second version was magically about 5 times faster. A combination of better algorithms and less bugs.

This is the grand lesson of Fabian.
Examine his original fruit code and the marvelous use of asserts.
He almost proves his program.

The eval was very good. Better than other evaluations of the time.
The search was very good. Better than other searches of the time.

But the biggest difference was meticulous attention to correctness.

[Steve Maughan]

I can agree with the advice about bug free code.
I rewrote my first program with the knowledge gained, and the second version was magically about 5 times faster. A combination of better algorithms and less bugs.

This is the grand lesson of Fabian.
Examine his original fruit code and the marvelous use of asserts.
He almost proves his program.

The eval was very good. Better than other evaluations of the time.
The search was very good. Better than other searches of the time.

But the biggest difference was meticulous attention to correctness.

+1

Wise advice indeed. Fabien changed the way I code.

Steve

[Henk]

The biggest lie is that after playing many games you assume that everything is working fine for Elo didn't drop and all games finished properly.

Information on user level only telling you lies all the time.

[For lazy testers "code that is not there can't go wrong" as HGM already told us]