how much faster (knps) is a 12-core over a single core when running r4?
12-core (6x2) at 4.2ghz (i.e. paul's rig): 917 knps
single core on paul's comp: 152 knps
scaling efficiency based on single-core: 50%
some things worth mentioning:
1. r4 seems to scale better as clock speed increases! we get 917knps at 4.2ghz, but 980knps at 4.3ghz. and we have 1019 at 4.4ghz. any idea why this is so?
2. we know the more cores on a chip, the better the scaling. it seems r4 (maybe all engines?) benefits more from higher ghz than from more cores. which raises the question: when sandy/ivy-bridge comes out (it'll have 8 cores on 1 chip), will it perform better than a 12-core (6x2) system at the same clock speed?
2. seeing how the scaling efficiency is only 50% w/ 12-cores (6x2), it's clear why vas created the cluster version of r4: to get around this scaling bottleneck.
12-core (6x2) at 4.2ghz (i.e. paul's rig): 917 knps
single core on paul's comp: 152 knps
scaling efficiency based on single-core: 50%
some things worth mentioning:
1. r4 seems to scale better as clock speed increases! we get 917knps at 4.2ghz, but 980knps at 4.3ghz. and we have 1019 at 4.4ghz. any idea why this is so?
2. we know the more cores on a chip, the better the scaling. it seems r4 (maybe all engines?) benefits more from higher ghz than from more cores. which raises the question: when sandy/ivy-bridge comes out (it'll have 8 cores on 1 chip), will it perform better than a 12-core (6x2) system at the same clock speed?
2. seeing how the scaling efficiency is only 50% w/ 12-cores (6x2), it's clear why vas created the cluster version of r4: to get around this scaling bottleneck.
You count like a mathematician: 1, 2, 2
When things scale better than linear in a situation like this, it usually indicates there is periodic overhead involved at a rate that is not dependent on the clock. For instance, Vas may be updating his sampled search at a 1 Hz rate, or something like than. This is less of a burden on a faster processor.
When things scale better than linear in a situation like this, it usually indicates there is periodic overhead involved at a rate that is not dependent on the clock. For instance, Vas may be updating his sampled search at a 1 Hz rate, or something like than. This is less of a burden on a faster processor.
![[gb]](/mwf/v12/flags/gb.png "United Kingdom")
Alan we can only play around with what we have got and evidence we can see with our own eyes.
vapochill, anyone?
when Tony returns from holiday he intends to blast eyeryone out and if he needs my help it could be lots of fun.i am retired and have a few quid spare so this could be a lot of fun.things went dead on this forum for a while.trust me it will change
things went dead on this forum for a while.trust me it will change
i smell 5.5ghz!
but dont push your luck,we are very down to earth guys.his son is under 21 kick-boxing champion in UK.
btw,this without Large Pages.
![[mx]](/mwf/v12/flags/mx.png "Mexico")
My theory: Vas's algorithm for recalculating the node count breaks somewhere.
Remember that Rybka obfuscates her nodes, so what you're looking at is at layers of recalculations so that Rybka doesn't really show her true node counts.
Try this:
Set one Rybka to play at 8 cores, and another to play at 2 cores, but underclock the 8's until Rybka shows in average the same nodes as the two cores, according to Vas the result should be 50% because Rybka is looking at the same number of nodes, but I'd expect the 8core to win by a significant score, signaling that the node recalculations are significantly inaccurate.
If underclocking isn't an option, I'd suggest using time handicap so that the 8core gets less time and searches the same nodes of the 2core, with the same result.
Remember that Rybka obfuscates her nodes, so what you're looking at is at layers of recalculations so that Rybka doesn't really show her true node counts.
Try this:
Set one Rybka to play at 8 cores, and another to play at 2 cores, but underclock the 8's until Rybka shows in average the same nodes as the two cores, according to Vas the result should be 50% because Rybka is looking at the same number of nodes, but I'd expect the 8core to win by a significant score, signaling that the node recalculations are significantly inaccurate.
If underclocking isn't an option, I'd suggest using time handicap so that the 8core gets less time and searches the same nodes of the 2core, with the same result.
well unfortunately i neither have an octal nor rybka. so someone else will have to perform your proposed experiment. i recall vas said on more cores the search tree will be wider. so the rybka running on the system w/ more cores may score higher, but i dont know if it'll be significantly so.
> i recall vas said on more cores the search tree will be wider.
He was talking about giving them the same depth regardless of time used (so if one engine takes 1 minute to reach depth 24, and another took 20 seconds, it's to be expected that the one taking one minute would win, since it used the extra 40 seconds to see relevant information).
I am talking about giving them the same nodes, with the premise that they're calculating them wrong, that is, it'd be possible to make a node recalculation algorithm where both engines get the same number and score 50% against each other, regardless of hardware, but that the current algorithm isn't doing it.
![[us]](/mwf/v12/flags/us.png "United States")
> unfortunately i neither have an octal nor rybka
You should buy Rybka. It'll make it more fun to post on the Rybka Discussion forum!
But perhaps he should go with Rybka 3!
Vas' algorithm for recalculating node count certainly doesn't know what clock speed you're running at, so it's very unlikely that this could cause a greater than linear speed up for using the same setup at a higher clock rate. The only exception to this would be if the node count itself, which is calculated periodically, is nonlinear (and this would be very, very strange, even for Vas).
![[fr]](/mwf/v12/flags/fr.png "France")
> how much faster (knps) is a 12-core over a single core when running r4?
see
http://rybkaforum.net/cgi-bin/rybkaforum/topic_show.pl?pid=165304#pid165304
your formula gives 5.5x, while the results show 6.0. that's quite close!
Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill