Can an engine with few nodes/second be strong?

[JBNielsen]

Is there any significant relation between rating and nodes/second?

My engine Dabbaba has few nodes/second, as it fx spends much time in preordering moves.

[Laskos]

Is there any significant relation between rating and nodes/second?

My engine Dabbaba has few nodes/second, as it fx spends much time in preordering moves.

Broadly, rating is proportional to log nps. But this is broadly.

[Vinvin]

Is there any significant relation between rating and nodes/second?

My engine Dabbaba has few nodes/second, as it fx spends much time in preordering moves.

Houdini 1.5 , 1 thread : 1 Mnps on my comp, rating -> 3220.2
Fritz 5.32 , 1 thread : 2 Mnps on my comp, rating -> 2594.60

Is it a valid answer to your question ?

[JBNielsen]

Is there any significant relation between rating and nodes/second?

My engine Dabbaba has few nodes/second, as it fx spends much time in preordering moves.

Houdini 1.5 , 1 thread : 1 Mnps on my comp, rating -> 3220.2
Fritz 5.32 , 1 thread : 2 Mnps on my comp, rating -> 2594.60

Is it a valid answer to your question ?

Thanks; it helps

Dabbaba searches 120.000 n/s in the starting position.
Wonder what rating the strongest program with so few n/s has....

Something like Houdini running 8 times slower and still having a rating of 3000+

[ZirconiumX]

If the few nodes are perfectly searched, then yes.

Matthew:out

[Vinvin]

Is there any significant relation between rating and nodes/second?

My engine Dabbaba has few nodes/second, as it fx spends much time in preordering moves.

Some things to consider :
- the more you optimize the code, the more faster your program will run
- the more you add in knowledge, the more slower your program will run
- the more you add in knowledge, the more your program will find good moves (at fixed analyzed nodes)
- the more you prune lines, the more your program will reach big depth (try to prunes bad lines and try to not prunes good lines...)
- ...

[lucasart]

Is there any significant relation between rating and nodes/second?

My engine Dabbaba has few nodes/second, as it fx spends much time in preordering moves.

Having a good move ordering, even if takes a bit of time, is certainly a good thing, as it reduces your branching factor. However, besides the usual tricks (SEE, MVV/LVAA, History, Killers, Hash Move), I don't know of any magic that improves significantly the ordering.

I don't know what/how you do it, but a few nodes per seconds is really really slow. There must be something very wrong with your code, and perhaps it's time to use a profile, to see what is happening. Modern engines combine: complex eval and move ordering *and* speed efficiency. It shouldn't have to be one or the other, unless coded very poorly.

Besides, if you only do a few nodes per seconds, it means that you can't even finish a simple qsearch() in many positions... That means you can't finish depth one, and you're likely to return an illegal or stupid move.

I would be curious to understand what the hell your program is doing for *so long* in the move ordering.

[Uri Blass]

Is there any significant relation between rating and nodes/second?

My engine Dabbaba has few nodes/second, as it fx spends much time in preordering moves.

Having a good move ordering, even if takes a bit of time, is certainly a good thing, as it reduces your branching factor. However, besides the usual tricks (SEE, MVV/LVAA, History, Killers, Hash Move), I don't know of any magic that improves significantly the ordering.

I don't know what/how you do it, but a few nodes per seconds is really really slow. There must be something very wrong with your code, and perhaps it's time to use a profile, to see what is happening. Modern engines combine: complex eval and move ordering *and* speed efficiency. It shouldn't have to be one or the other, unless coded very poorly.

Besides, if you only do a few nodes per seconds, it means that you can't even finish a simple qsearch() in many positions... That means you can't finish depth one, and you're likely to return an illegal or stupid move.

I would be curious to understand what the hell your program is doing for *so long* in the move ordering.

few is 120,000 per second in the case of the discussion so there is no risk
not to finish depth 1.

[lucasart]

few is 120,000 per second in the case of the discussion so there is no risk
not to finish depth 1.

Oh I see. Without a number, it was hard to know what he meant by "few". 120k is not very fast, but you can still have a very strong engine like that.

[Don]

Is there any significant relation between rating and nodes/second?

My engine Dabbaba has few nodes/second, as it fx spends much time in preordering moves.

Nodes per second is highly correlated to strength but this only goes so far ...

Some programs do a LOT more with 1 node than another and many heuristics that hurt nodes per second but helps ELO, including evaluation features like mobility.

But of course it's obvious that any give program will play stronger if you increase the nodes per second while doing nothing else differently.

Komodo is a good example of a program that is very strong with relatively low nodes counts. Fritz is a good example of reasonably strong program that has very high node counts but doesn't match the top programs in strength despite racking up a lot of nodes.

Don