Improving speed

[Henk]

Infinite.

But indeed there may not be a speed bug. Perhaps other engines do more null moves and that increases speed.

Just the word "speed" itself is vague and causes a problem when not communicated clearly. Do you mean nodes per second? Do you mean time to depth? Do you mean time to solve a particular test position?

Each part of your engine will affect each of the above (and other things) very differently. Null moves, like other reduction methods, will affect time to depth more than anything else, but not have much as affect on NPS.

It is about NPS. Yes null moves have not much affect on NPS. I disabled null moves and NPS was not changing much.

I disabled all evaluations and still it is at least two times slower than some other engines. This means Skippers implementation of basics is much too slow.

But if you would improve the speed (in NPS) of Skipper by, say, a factor of four - assuming you would not introduce new bugs by doing so - then you would get a strength improvement of roughly 150-200 Elo points, not more. And still Skipper would be a very weak engine. So do you realize that the main problem is not NPS?

Typical implementation topics where bugs may have a very high impact on playing strength include, for instance:
- move ordering
- quiescence search
- hash table
- evaluation (especially when using abnormally high scores)

The more code you have the worse it gets to change a basic data structure. So best to start as soon as possible. Assuming size of code only grows.

I am not talking about changing data structures but about watching out for bugs in the code in general. Please note also that I edited my previous post a few minutes ago.

Congratulations Sven for your great patience
Speaking with this guy is like speaking with a wall
He never listen others advices , boring

We already know you are Skippers best fan.

[mjlef]

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.

Nodes per Second is not a good measure. You want to maximize strength, not nps. If you want higher nos, do not do SEE on moves. Have random move ordering, and your nps will increase dramatically, and make your program much weaker.

Most elo gaining changes in Komodo are slowdowns. For example, most programs in qsearch pruning losing (based on SEE) moves. This takes time, but results in a smaller tree with less nps. Smaller trees, as long as they do not miss much, means your program can search deeper. Depth increase is a much better measure of playing strength.

There are some pure speedups, which do not change the search tree and so do increase nps. But I suggest concentrating on tree size and pruning schemes. I think you will make much faster progress concentrating on this.

[Henk]

Maybe best to minimize tree_size/speed. Assuming no essential nodes are skipped.