Threading and Performance
Multi-threaded software as a scalability answer is apparently harder than most people think. Consider:
With both SQL Server and Citrix Terminal Server installations, HT-enabled motherboards show markedly degraded performance under heavy load. Disabling HT restores expected levels, according to reports from within the IT industry.
I've recommended multiple processes vs. multiple threads for years, but most people figured I said that because VisualWorks doesn't map Smalltalk threads to platform threads. It's not just me though:
"It's ironic," said Ibbotson. "Intel had sold hyperthreading as something that gave performance gains to heavily threaded software. SQL Server is very thread-intensive, but it suffers. In fact, I've never seen performance improvement on server software with hyperthreading enabled. We recommend customers disable it when running Citrix and our software on the same server"
Of course, this doesn't help matters much either:
Earlier this year, Intel hyperthreading was revealed to have a security flaw where threads could find information from each other through the shared cache despite having no access to each other's memory space.
I'd be more interested in knowing whether that flaw can be accidentally exploited to cause problems in an application.
Comments
HT, Security Flaw
[murphee (http://jroller.com/page/murphee)] November 20, 2005 16:55:44.151
Just because Intels version of SMT (== "Hyperthreading") doesn't always produce good results, doesn't mean that multithreading is flawed, There are also benchmarks (even not from Intel), that show applications that benefit from HT.
About the security flaw: I'm not sure whether you really don't know about it or whether you're just trying to spread a bit of FUD about multithreading.
In any case: it is a timing attack, which is a type of side-channel attack. It basically means, that you can somehow measure memory accesses or the pattern of memory accesses of an application. In some cases, this information can be used to get *some* information about what the processor is doing.
As you can gather from the explanation: this is **far** from trivial, and you'd have to spend a lot of time even finding some way to exploit an application simply with these access timings.
Compare it to this: say you're in a room with a painter. You have your eyes closed, and the painter starts to do a painting. You only get the acoustic information (ie. strokes on the canvas, scratching on the palette, dipping the brush in the colors,... ) .
After an hour the painter says "finished" and you have to tell what is standing to the left of the duckbilled platypus (which the painter painted).
Not to mention, that to exploit this "flaw" you'd have to run on the same computer that the targetted application runs on. I don't know if it can actually *be* a different application that commits the attack (I don't think threads from different processes are scheduled at the same time with HT), but I'm not sure about this.
About the bug
[ James Robertson] November 20, 2005 19:57:02.413
Comment by James Robertson
I didn't know details. It's an honest question.
[Ziv Caspi] November 21, 2005 12:24:29.389
Note, however, that the issues you've raised with HT have nothing to do with the multi-threading vs. multi-processing issue. In fact, if SQL Server were to employ multi-processing, the same issues would arise (and its performance considerably drop).