Improving speed

[Sven]

I removed occupier property from my Field or Square class. So now it is bit board only. Very handy for debugging (not). Again I had to change about 400 lines of code.

And guess what speed is 10-20% slower. But at least I know it was not causing the speed bug.

And what if there is no speed bug but an attitude bug? How many lines would you have to change in order to fix that?

[Henk]

Infinite.

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

[JVMerlino]

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.

[smcracraft]

Bob Floyd at Stanford (Knuth's collaborator) changed the way I code.

Bob lectured over and over and over to us students about asserts in code (this was back in the 1970's.)

His lectures were fun, not heavy, and were rather like surfing, topic to topic, interesting.

Here's his official obit from the university some years ago

https://www-cs.stanford.edu/memoriam/pr ... rt-w-floyd

[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.

[Sven]

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 relatively high scores)
- all sorts of code that deals with the final move decision (example: playing the best move from the previous iteration even though the current iteration has already refuted it and found a better move, but was stopped by timeout)

So you might want to check again whether there is any severe problem in one of these areas ...

[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.

[Sven]

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.

[Daniel Anulliero]

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

[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 all know you are my best fan.