lmader wrote:
Ahhhh, ok. I am at peace now
We can agree that HT CPUs aren't always slow.
And yes, the L1/L2 caches getting wiped out by one thread, and various other issues can result in performance loss with HT. Whether it's an overall, general system gain for the average user is probably unclear, but I do notice that my old P4 system with a gig and half of memory runs Vista more smoothly than with the HT off. Perhaps Vista has optimized the scheduler well.
I use Windows XP and only have an acceptably responsive Pentium IV machine if HT is active.
Whoever can say whatever he likes, but the fact remains that HT is a very welcome measurable gain in practice, independent of theory I don't understand
lmader wrote:
Ahhhh, ok. I am at peace now
We can agree that HT CPUs aren't always slow.
And yes, the L1/L2 caches getting wiped out by one thread, and various other issues can result in performance loss with HT. Whether it's an overall, general system gain for the average user is probably unclear, but I do notice that my old P4 system with a gig and half of memory runs Vista more smoothly than with the HT off. Perhaps Vista has optimized the scheduler well.
I use Windows XP and only have an acceptably responsive Pentium IV machine if HT is active.
Whoever can say whatever he likes, but the fact remains that HT is a very welcome measurable gain in practice, independent of theory I don't understand
I did not have time to run a lot of tests, but here are three different positions that sort of illustrate what I expect from hyperthreading. The first position is always run with SMT on, just using one CPU. The second run is same position, mt=2 (SMT always on). The third run is same again but with mt=4 since this box has 2 physical processors which support SMT.
This is one of those "good positions" that actually produces a better-than expected speedup with 2 cpus. Notice that the tree size is actually smaller than the one-cpu tree which accounts for the super-linear speedup of 2.12X. Notice that with two threads, the NPS is almost exactly double, which is expected. With SMT on and 4 threads however, the nps does climb very slightly about 5% roughly. So 5% faster nps, .1 second faster time. OK.
Again speedup for 2 looks good, speedup for 4 is slightly worse than for 2, no NPS improvement at all for four.
Only good thing is that with SMT on, the linux process scheduler uses two run queues, one for each physical processor, so that if you have just two processes ready to run, each always runs on a different physical processor, which old versions of the kernel did not do at all. So you can leave it on and by using just two threads, get good performance. But going to 4 is a losing proposition at worst, a break-even at best. And these positions are known for being pretty good speedup-tests. There are worse positions that show SMT in a worse light...
Note that 4 threads is almost 2x slower than 2 and is barely faster than just one.
So for crafty, NPS improvement is minimal, between 0 and 5%, while search overhead stays solidly at 30% + most of the time... There is a moral. 4 cpus that are each as fast as the one original works well. But given the choice of two x ghz processors, or four x/2 ghz processors, I'll take the 2 x ghz processors every time, where smt gives you 4 x/2 that are not as efficient for chess and very little faster in terms of raw nps...
Matthias Gemuh wrote:
I use Windows XP and only have an acceptably responsive Pentium IV machine if HT is active.
Whoever can say whatever he likes, but the fact remains that HT is a very welcome measurable gain in practice, independent of theory I don't understand
Matthias.
It can also be a "placebo effect" as well...
A "placebo effect" that speeds up systems significantly, makes them more responsive and much more stable is always welcome.
Matthias Gemuh wrote:
I use Windows XP and only have an acceptably responsive Pentium IV machine if HT is active.
Whoever can say whatever he likes, but the fact remains that HT is a very welcome measurable gain in practice, independent of theory I don't understand
Matthias.
It can also be a "placebo effect" as well...
A "placebo effect" that speeds up systems significantly, makes them more responsive and much more stable is always welcome.
Matthias.
My point was that this is something that is not quantatively measured. I have been running with SMT on on my box, compiling, playing chess, browsing. I don't notice _any_ difference at all.
As far as "much more stable" that makes no sense to me at all. I have yet to see a "speeds up systems significantly" on anything I do. Which would primarily be compiling, executing, and other such things on several different "number crunching" applications, of which chess is just one. "makes them more responsive" doesn't work for me. I can tell absolutely no difference with SMT on or off on my linux box using recent kernels.
The "placebo effect" is well-documented, as believing in something is often enough to make things seem better, whether they really are or not is another issue. I can't help but notice that after the PIV SMT went the way of the dinosaurs for a while, which suggests that it was not worthwhile for most.. Bringing it back doesn't necessarily mean it is better. It might be just another "gimmick" for sales hyperbole...
