Hyperthreading

[Gerd Isenberg]

In Agner Fog' CPU Blog, Alain Amiouni mentiones chess engines run faster when Hyperthreading (Intel Core i7) is on and affinities are set, than when HT is off. Guess in both cases the number of chess threads is restricted to one per core. Is that confirmed and is it more than negligible? Also is it possible with w64 api calls and linux as well, to map threads to even-numbered logical processors?

[bob]

In Agner Fog' CPU Blog, Alain Amiouni mentiones chess engines run faster when Hyperthreading (Intel Core i7) is on and affinities are set, than when HT is off. Guess in both cases the number of chess threads is restricted to one per core. Is that confirmed and is it more than negligible? Also is it possible with w64 api calls and linux as well, to map threads to even-numbered logical processors?

Makes no sense to me. I ran extensively on a Nehalem box. There are three options, and I am assuming for all three of these, "turbo-boost" is set to "off".

1. HT off. using 8 threads, speedup is exactly what is expected.

2. HT on. Using old Linux kernels, things go bad, because if you use 8 threads, you can (worst case) get all 8 on one physical chip, leaving 1/2 your _real_ computing resources unused. More recent kernels don't have this problem and using 8 threads with 8 physical cores, 16 logical cores, Linux will attach one physical thread to one physical core, exactly as you would like. So here, ht=on or ht=off is irrelevant. Older systems (windows and Linux) could be problematic however.

3. HT on, using 16 chess threads. Always worse. HT gives a little performance boost, but the extra eight threads give _way_ more extra nodes searched (search overhead) making this a loser for any chess engine, unless perhaps a new one that is not very efficient to start with. But a mature SMP search is not going to do better because of the overhead dwarfing the small NPS gain.

I would not be surprised if "runs faster" means "higher NPS". That's not the important number, any more than a tach reading is more important than the speedometer reading. If they don't understand that time-to-depth or time-to-solution is the key measurement, they could assume that bigger NPS = better, even though with HT on, bigger NPS comes with longer time to solution.

[rbarreira]

Yeah your parallel algorithm would probably have to be impossibly perfect (at least by today's standards) in order to take advantage of a small increase in NPS when the number of threads is doubled.

If for some reason you use a lot of memory for each thread, then it could be even worse as you could have a bigger hash table by having half the number of threads.

[bob]

Yeah your parallel algorithm would probably have to be impossibly perfect (at least by today's standards) in order to take advantage of a small increase in NPS when the number of threads is doubled.

If for some reason you use a lot of memory for each thread, then it could be even worse as you could have a bigger hash table by having half the number of threads.

Actually, lots of memory accesses is the thing that makes hyperthreading work. Where an operating system blocks a process when it does I/O, hyper-threading 'blocks' a process when it stalls for a memory read, or less significantly, when waiting for some other resource that is unavailable.