[Qt4-preview-feedback] Qt 4.5 QMutex spin mechnism poor performance

[Martin Dyde]

Hello Qt team,

Background: our product is very CPU-intensive real-time audio 
application (a virtual pipe organ), which is highly optimised for 
multi-core CPUs and/or full multi-processor systems (it has intelligent 
load-balancing between CPU-cores, is NUMA-aware, etc.), and for which 
performance is critical because it needs to achieve an enormous 
polyphony (number of simultaneous audio streams) with very low latency 
(e.g. typically less than 6 milliseconds).  Many of our users buy 
expensive multi-processor computers specifically to achieve the 
polyphony they need, which can often be in excess of 5000 simultaneous 
audio streams.  Our audio engine threads have to run with very high 
priorities to manage this, so wasting CPU cycles can give a big 
performance hit on other threads that need to run simultaneously on a 
given CPU core, as can unnecessary context switches.

I'd been seeing a drop in performance when moving from Qt 4.4.3 to Qt 
4.5, and I've tracked it down to a change implemented in Qt 4.5's 
QMutex::lock() fn, in which you've added a new 'mutex spinning' 
mechanism which repeatedly re-tries to get the lock from the OS, rather 
than just waiting on it.  This causes approximately a 25 percent drop in 
overall application performance (polyphony) in our case, i.e. a very 
significant and measurable degredation.

If I manually remove the new spin code from the Qt src, so that 
QMutex::lock() behaves the same as it did in Qt 4.4.3, then all is well 
again and we get that 25 percent of performance back.

I appreciate that there might be some cases where the spinning mechanims 
could give improved performance, but for our type of application it's 
very definitely (and measurably) much worse.

Since we have a work-around for it (a custom edit to the Qt src to take 
out the spin functionality), it isn't a high priority for us, but my 
request would be for the longer term that you could make the spin 
functionality optional - perhaps a new QMutex property to avoid having 
the overhead of having to to pass an extra bool to QMutex::lock() or 
QMutexLocker with each call?  Or, probably better still, a 
precompiler/configure option to avoid the spin code (and also avoid a 
runtime condition) altogether?

Many thanks and best regards,

Martin Dyde,
Milan Digital Audio LLC.
http://www.crumhorn-labs.com/
http://www.milandigitalaudio.com/