Best engine for greater than 8-core SMP system

[ernest]

you are acting like a bad loser: that 874 is obviously nonsense...

[Vinvin]

In fact, no, the NPS reported by Rybka already take account of the speed lost by adding more CPU's. I think Vas is the only top programmer doing that.

Thanks for the link. So it appears a 12T Rybka does search more nodes, but only 50% more than a 4T Rybka... Without time-to-ply there is no way to know if this would actually perform better. My guess is that the 12 core systems would actually perform worse than the 4 core, core i7 at 4.31 Ghz.

KNPS
1620 2x Intel Xeon X5667 4.50GHz x64 12 CPUs Kim Burcham
1331 2x Intel Xeon X5650 4.00GHz x64 12 CPUs Ruben Comes
1013 Intel Core i7 980X 4.41GHz x64 6 CPUs Martin Thoresen
966 Intel Core i7 980X 4.50GHz x64 6 CPUs Roland Acosta
874 Intel Core i7 920 4.31GHz x64 4 CPUs Tsvetan Milchev

[Milos]

In fact, no, the NPS reported by Rybka already take account of the speed lost by adding more CPU's. I think Vas is the only top programmer doing that.

You can't take into account something that has an unknown quantity.
Speed loss is highly dependent on the actual position (it can differ multiple times between different positions), so there's absolutely no sense including some correction like this if you can not accurately measure it. And the only way to accurately measure it would be to benchmark each position during analysis. I'm pretty certain Rybka doesn't do that, so that's just another myth about Vas's programming ingenuity.

[tomgdrums]

In fact, no, the NPS reported by Rybka already take account of the speed lost by adding more CPU's. I think Vas is the only top programmer doing that.

You can't take into account something that has an unknown quantity.
Speed loss is highly dependent on the actual position (it can differ multiple times between different positions), so there's absolutely no sense including some correction like this if you can not accurately measure it. And the only way to accurately measure it would be to benchmark each position during analysis. I'm pretty certain Rybka doesn't do that, so that's just another myth about Vas's programming ingenuity.

You are only pretty certain so it might not be a myth.

[Uri Blass]

In fact, no, the NPS reported by Rybka already take account of the speed lost by adding more CPU's. I think Vas is the only top programmer doing that.

You can't take into account something that has an unknown quantity.
Speed loss is highly dependent on the actual position (it can differ multiple times between different positions), so there's absolutely no sense including some correction like this if you can not accurately measure it. And the only way to accurately measure it would be to benchmark each position during analysis. I'm pretty certain Rybka doesn't do that, so that's just another myth about Vas's programming ingenuity.

You can certainly may have an estimate for the average speed loss so you simply multiply the nodes that you get by a factor based on the number of cores(the question if the number of node represent the speed loss in some specific position is totally unimportant.

[Vinvin]

In fact, no, the NPS reported by Rybka already take account of the speed lost by adding more CPU's. I think Vas is the only top programmer doing that.

You can't take into account something that has an unknown quantity.
Speed loss is highly dependent on the actual position (it can differ multiple times between different positions), so there's absolutely no sense including some correction like this if you can not accurately measure it. And the only way to accurately measure it would be to benchmark each position during analysis. I'm pretty certain Rybka doesn't do that, so that's just another myth about Vas's programming ingenuity.

May be you're pretty certain it's false but it's well known for more than 2 years : http://rybkaforum.net/cgi-bin/rybkaforu ... ?pid=85218

"Rybka's kn/s figure doesn't increase much when she runs on machines with more processors, compared to other programs. Does this mean that she scales worse on such hardware?

No. Rybka's kn/s on multi-processor machines reflects the estimated multi-processor efficiency, so that her kn/s figures provides a true speedup. Other engines typically display literal node counts, which include many "wasted" nodes, and this can give a false impression of a better multi-processor scaling."

[Milos]

You can certainly may have an estimate for the average speed loss so you simply multiply the nodes that you get by a factor based on the number of cores(the question if the number of node represent the speed loss in some specific position is totally unimportant.

Wrong.
Just take a look at Bob's paper and you'll see how much speed loss differs in different positions. Reporting average number is totally meaningless since accuracy is terrible.
Rybka might be doing that, however, scaling completely obscured and ridiculous node number with something so inaccurate is just idiotic.
Vas doesn't give a damn, problem is that there are so many ppl who blindly believe him like sheep.

Anyway, trying to convince religious fanatics from Vas cult into something is just mission impossible...

[bob]

You can certainly may have an estimate for the average speed loss so you simply multiply the nodes that you get by a factor based on the number of cores(the question if the number of node represent the speed loss in some specific position is totally unimportant.

Wrong.
Just take a look at Bob's paper and you'll see how much speed loss differs in different positions. Reporting average number is totally meaningless since accuracy is terrible.
Rybka might be doing that, however, scaling completely obscured and ridiculous node number with something so inaccurate is just idiotic.
Vas doesn't give a damn, problem is that there are so many ppl who blindly believe him like sheep.

Anyway, trying to convince religious fanatics from Vas cult into something is just mission impossible...

"Estimates" are just that... and for parallel search they are beyond "estimates" and venture into the realm of "guesses". I used to gather parallel search statistics in Cray Blitz and early Crafty versions, but decided the numbers were useful for nothing more than random values... They are all over the place. The same position, same hardware can vary by a factor of 5x (measuring time, nodes, whatever you want to measure) between two identical runs.

Best number to present is just raw NPS which does give some idea of the spped of the program and/or hardware, but says nothing about time-to-solution which is the only value that matters in real games...

[bob]

In fact, no, the NPS reported by Rybka already take account of the speed lost by adding more CPU's. I think Vas is the only top programmer doing that.

You can't take into account something that has an unknown quantity.
Speed loss is highly dependent on the actual position (it can differ multiple times between different positions), so there's absolutely no sense including some correction like this if you can not accurately measure it. And the only way to accurately measure it would be to benchmark each position during analysis. I'm pretty certain Rybka doesn't do that, so that's just another myth about Vas's programming ingenuity.

May be you're pretty certain it's false but it's well known for more than 2 years : http://rybkaforum.net/cgi-bin/rybkaforu ... ?pid=85218

"Rybka's kn/s figure doesn't increase much when she runs on machines with more processors, compared to other programs. Does this mean that she scales worse on such hardware?

No. Rybka's kn/s on multi-processor machines reflects the estimated multi-processor efficiency, so that her kn/s figures provides a true speedup. Other engines typically display literal node counts, which include many "wasted" nodes, and this can give a false impression of a better multi-processor scaling."

Keyword "true speedup" which is a crock. One can't predict "true speedup" one has to run the position several times and average the results to get an idea of "true".

This should be re-stated as "provides a very rough approximation to a number that has a very large statistical variance." Or "provides a number that may or may not mean anything at all since it is based on a single sample."

[M ANSARI]

Rybka nodes with more than 8 cores are under valued. I remember on a 48 core AMD machine the nodes were unusually low, but the scaling of the 48 cores strength wise (ELO strength) seemed to follow traditional scaling gains when strength tested. I don't think that Rybka has a proper method of giving an accurate guesstimate to what knps it should show for more than 8 cores, but it scales quite well at higher cores, and I would disregard the knps shown as a pointer to performance.

One more thing, although Rybka seems to be the best scaling engine on more than 8 cores today, Zappa Mexico II also has excellent scaling even though its search and evaluation might be outdated. Rybka only managed to reach the scaling of ZM II with R3, and it lagged quite a bit in scaling before that.