![[us]](/mwf/v12/flags/us.png "United States")
to use hyperthreading or not.
![[in]](/mwf/v12/flags/in.png "India")
not for any engine
![[gb]](/mwf/v12/flags/gb.png "United Kingdom")
it depends what you are doing with the engine?
![[mx]](/mwf/v12/flags/mx.png "Mexico")
For whatever he's going to use it, HT is going to slow him down.
I assume this is not a serious response?
I'm serious, but I'm talking about the engine (not a group of engines each running on 1CPU or using affinities.)
Well, if, for example, he is using an engine that loses lets say 5% of its speed by having HT on and he is using this same engine in a blitz tournament then I would agree with you - if on the other-hand he is using his engine to analyse a position and the engine is given several hours on the position, then a 5% reduction in speed is neither here or there - the degradation in performance must be related to how you are going to use the engine and on the hardware {number of CPUs} you are using.
> if on the other-hand he is using his engine to analyse a position and the engine is given several hours on the position, then a 5% reduction in speed is neither here or there
There should be slowdown, reflected in the node count.
Yes, but that's like saying, if I hold a balloon in front of me and you fire a bullet from the most powerful handgun in the world from 4 feet away the balloon will slow the bullet down before it enter's my chest - it will still kill me!
Whilst I would agree with you that it slows the node count down, it won't make any difference to the information you will get from the engine - even on a dual-core machine, most of the top engines find very strong moves in just a few minutes so if you are using an engine to analyse a position and leave it to analyse for around an hour or two what difference does it actually make to the window of moves you will find in the engine pane - answer: absolutely none whatsoever.
Whilst I would agree with you that it slows the node count down, it won't make any difference to the information you will get from the engine - even on a dual-core machine, most of the top engines find very strong moves in just a few minutes so if you are using an engine to analyse a position and leave it to analyse for around an hour or two what difference does it actually make to the window of moves you will find in the engine pane - answer: absolutely none whatsoever.
Razor,
Can I just clarify what you're saying: there is little / no benefit to long term analysis?
I have noticed that just OCCASIONALLY leaving my machine on overnight does yield something startling.
Can I just clarify what you're saying: there is little / no benefit to long term analysis?
I have noticed that just OCCASIONALLY leaving my machine on overnight does yield something startling.
No, that is not what I'm saying. I'm saying {to use your example} that where you are analysing a position for several hours having HT on or off really doesn't make a significant difference to the outcome of the engines findings. Clearly if you reduce the amount of time you give the engine to think {e.g., blitz games} then yes, HT on has a significant impact on the engine analysis and therefore the justification/need of the situation for turning HT off increases.
OK, thanks.
![[de]](/mwf/v12/flags/de.png "Germany")
If a loss of (guessed) 5% of performance is significant in short games - why should it be insignificant in long analysis?
I was asking myself the same thing. Here's an argument....
the first 10,000 nodes are more important then the next 10,000 nodes in achieving an accurate move. Equally and the first 100,000 nodes are more improtant than the next 100,000 nodes etc. So losing 5% or the early nodes costs you more than losing 5% of the later nodes. Or to put it another way, you might go from say 70% to 80% best move choice with an extra 5% nodes per second at blitz, but from say 95% to 97% best move choice with an extra 5% at long time controls.
Whether this translates in to a bigger impact on game results is not so clear. If I have nothing better to do I might make a comparison of the rating list reuslts at different time controls and processing power. That shoud give an objective answer.
the first 10,000 nodes are more important then the next 10,000 nodes in achieving an accurate move. Equally and the first 100,000 nodes are more improtant than the next 100,000 nodes etc. So losing 5% or the early nodes costs you more than losing 5% of the later nodes. Or to put it another way, you might go from say 70% to 80% best move choice with an extra 5% nodes per second at blitz, but from say 95% to 97% best move choice with an extra 5% at long time controls.
Whether this translates in to a bigger impact on game results is not so clear. If I have nothing better to do I might make a comparison of the rating list reuslts at different time controls and processing power. That shoud give an objective answer.
No need to do any comparison.
You only explain why long analysis has diminishing returns.
But if someone decides he wants a long analysis - why should he waste 5% of preformance / time and 25% of electricity?
You only explain why long analysis has diminishing returns.
But if someone decides he wants a long analysis - why should he waste 5% of preformance / time and 25% of electricity?
Agreed.... no reason at all to waste 5%. I wouldn't :)
But the question still stands as to whether 5% has more impact on short or long time scales, and it is a question that interests me, so I will probably get round to the analysis over the next few days. It should only take half an hour or so.
But the question still stands as to whether 5% has more impact on short or long time scales, and it is a question that interests me, so I will probably get round to the analysis over the next few days. It should only take half an hour or so.
i assume that it will slow me down on 1 minute games. how about on infinite analysis where games are 1 move every 2 days? like in gameknot chess. would HT benefit more on the best move the R4 will make, say at least up to 21 depth?
![[nl]](/mwf/v12/flags/nl.png "Netherlands")
No.
This will save time:
HT never benefits.
HT never benefits.
HT doesn't benefit Rybka at any time control, but will benefit most other applications you have running on your PC, including the chess GUI. This is more important for short time control games than longer games. You will get optimal results from short TC games or when you are running other applications on your PC while analyzing with Rybka if you set Rybka to work with the number of physical cores you have, and then set the affinity of the Rybka processes to run on the even logical cores only.
i can only quote Lukas once again HT decrees Rybka performance by 18% and increases electric bill by 21%.
thx for the great info. i'll turn off HT then when i use R4. i would assume that the rybka cluster isn't on HT when Lukas uses his cluster pc
If you use affinity to run Rybka on even logical cores only, you aren't using HT for Rybka. You are using HT for other applications though, and the performance of most other applications are significantly improved. I'm pretty sure that this is actually what Lukas is doing (or at least he developed a script to apply affinities automatically since it would be a hellacious job to do it manually for the cluster).
i think,like myself Lukas only uses his big hardware for chess,cannot dispute you that it is good for other applications.
Even if you restrict to just chess, you still have other applications coming in, including the GUI, the OS, and if you are using TBs, the disk manager. All of these will have less impact on Rybka if HT is on, although in many cases the difference may be very small.
in that case Alan what do you recommened, Lukas would not have said this without extensive testing.he is a German after all.
- -/- By Lukas Cimiotti (*****) [de] Date 2010-06-29 01:45
HT on with affinities set using only physical cores is roughly 2% better than HT off.
HT on with affinities set using only physical cores is roughly 2% better than HT off.
maybe,but i also use large pages.21% on electric bill.?
Use of large pages should make Rybka benefit more from HT rather than less because execution unit utilization will be higher, making it more difficult for other processes to run without HT without suspending the Rybka process.
21% is the increase in electricity usage from increased execution usage from using HT with two cpu bound processes. If you are using HT to make the OS or the disk manager more efficient, the increase should be roughly equal to the increase in Rybka speed (2% in Lukas' experiment).
For most applications, use of HT is actually more energy efficient than non-use. The problem with its use for Rybka is the the gain from HT isn't big enough to overcome the loss from having more processes (Lukas has calculated this as 0.75^N).
21% is the increase in electricity usage from increased execution usage from using HT with two cpu bound processes. If you are using HT to make the OS or the disk manager more efficient, the increase should be roughly equal to the increase in Rybka speed (2% in Lukas' experiment).
For most applications, use of HT is actually more energy efficient than non-use. The problem with its use for Rybka is the the gain from HT isn't big enough to overcome the loss from having more processes (Lukas has calculated this as 0.75^N).
alan,i cannot argue these points and await like yourself Lukas reply.
I guess that you believe that the situation has changed from when Lukas made his post on 2010-06-29 @ 01:45.
Alan is right.
All of my computers run with hyperthreading enabled. I'm setting affinities of Rybka tasks to even numbered cores and all other stuff to odd numbered cores.
All of my computers run with hyperthreading enabled. I'm setting affinities of Rybka tasks to even numbered cores and all other stuff to odd numbered cores.
may i know the other stuff to put on odd numbers? maybe it may help not to slow down the R4 on HT mode. i did try the R4 on HT mode and played 1min games and i did noticed the slowing down of the R4. and this is on even numbers cpu affinities.
In my current setup I set a CPU mask of binary 101010101010101010101 to everything but Rybka and the system idle process. I'm doing this by a script. I haven't tested this very much, but for the cluster master I found good results.
Even when setting affinities, isn't 21% higher electric bill for 2% speedup a bad trade-off?
21% higher electric usage is for running two Rybka processes on a single physical core, not for turning on HT and using affinity to run only one Rybka process on each physical core. So if you're smart, you won't see this unless you are running some other cpu intensive application with Rybka, in which case the percentage extra work that gets done will exceed the percentage increase in electric usage.
Once again, HT is an energy saver for processes that scale linearly. It makes no sense for Rybka MP because of the 0.75^N relationship between processes and throughput. However, if you are running lots of Rybka single process instantiations to look at many unrelated positions, HT is probably a good idea as it results in an effective speed increase of 30%, if my memory serves me, while using 21% more energy.
Once again, HT is an energy saver for processes that scale linearly. It makes no sense for Rybka MP because of the 0.75^N relationship between processes and throughput. However, if you are running lots of Rybka single process instantiations to look at many unrelated positions, HT is probably a good idea as it results in an effective speed increase of 30%, if my memory serves me, while using 21% more energy.
i.e. if you ran 8 R4 SP processes on a quad with HT enabled, you would get 30% more throughput at a cost of 21% more energy. This is an excellent tradeoff when compared to overclocking, which always increase energy use more than throughput.
hope you notice this thread Lukas and await your reply.
thx guys for a great response that gave me a good idea to deal with HT in relation to using R4 engine.
The performance penalty has to be reconsidered as at the time I found this I didn't know about an issue in the calculation of nodes in Rybka.
thanks for clarification Lukas.so you recommened we switch HT on and on big hardware ignore R4 node count.
No - not really.
If you want to switch on HT on your computer, you should run Rybka with max CPUs set to 12 and a tool that sets affinities. The tool might look like this:
while (1)
{
$count = 0
foreach ($Rybka in Get-Process -ProcessName *Rybka*)
{
if ($count -lt $env:number_of_processors)
{
[int64]$cpumask = [math]::Pow(2,$count)
if ($Rybka.ProcessorAffinity -ne $cpumask)
{
$Rybka.ProcessorAffinity = $cpumask
write-host "Rybka task affinity set to core " $count
}
}
$count += 2
}
start-sleep -s 15
}
This is a little powershell script which checks affinities of Rybka tasks once in 15 seconds and sets them if necessary.
If you want to switch on HT on your computer, you should run Rybka with max CPUs set to 12 and a tool that sets affinities. The tool might look like this:
while (1)
{
$count = 0
foreach ($Rybka in Get-Process -ProcessName *Rybka*)
{
if ($count -lt $env:number_of_processors)
{
[int64]$cpumask = [math]::Pow(2,$count)
if ($Rybka.ProcessorAffinity -ne $cpumask)
{
$Rybka.ProcessorAffinity = $cpumask
write-host "Rybka task affinity set to core " $count
}
}
$count += 2
}
start-sleep -s 15
}
This is a little powershell script which checks affinities of Rybka tasks once in 15 seconds and sets them if necessary.
My wife must have one of these scripts for things she wants me to do around the house because she reminds me about them once every 15 seconds...
You can change the interval by editing the line "start-sleep - s 15" to something like "start-sleep - s 86400" - then it will only be checked once a day. Maybe something like this works for your wife too
No such luck!
lol. thats funny.
Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill