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/ _______________________________________________ Qt4-preview-feedback mailing list [email protected] http://lists.trolltech.com/mailman/listinfo/qt4-preview-feedback
