HyperThreading scores are Hyper- perplexing
It still doesn't add up
Friday's server briefings at Intel SC13 allowed the press an extended session to quiz Chipzilla on its recent benchmark adventures. But what we were particularly interested in was the question that's been vexing hardware sites since the spring: why HyperThreading - Intel's word for SMT - doesn't deliver all the benefits promised.
As we noted back in March (see Why isn't SMT Xeon scaling?", preliminary benchmarks showed a very mixed result. In some cases HyperThreading slowed the machine down. Although Alan Cox noted in a recent kernel list posting that enabling SMT could add a 10 to 30 per cent improvement, in some cases there was no gain. And in the German tech bible c't, Andreas Stiller recommended disabling HyperThreading on Windows systems altogether.
Intel's Jason Waxman, who looks after "performance marketing" - or in his words, the guy who cops it when a benchmark is shot down - pointed out that SMT was disabled by default in Xeon workstations. In short, Intel wasn't recommending multi-threading for everyone.
Yes, he acknowledged, cache contention was real: when two processor threads were vying for resources, one was bound to lose out.
Would he recommend that developers recompile for HyperThreading? No, but there was some things they could be done, such as improving thread affinity.
At this point a member of the press (no names here) came to Intel's rescue, by suggesting that ISVs were already beginning to rewrite their applications for SMT.
The look on Jason's face was a mixture of relief and horror. Relief, because he was delighted to see a journalist ride to the company's cause, but horror because much of the point of HyperThreading is that you don't have to rewrite your applications. In fact, it would be like a ferry company advising its passengers to bring their own wetsuits and dinghies.
Wisely Jason stopped short of endorsing this approach. The name of the game is increasing parallelism, and the presence of threads in the OS doesn't necessarily make for a more parallel work flow.
Intel itself has a C++/Fortran compiler that supports OpenMP pragmas and directives. OpenMP is a cross-platform initiative for tools vendors to optimize for shared memory multiprocessing: so it covers SMP as well as SMT.
There's also some interesting Intel labs work on speculative execution designed to speed up single threaded applications. We'll get some additional clarification in the next day or two. ®