On 8/22/12 7:58 PM, "ext Thiago Macieira" <thiago.macie...@intel.com> wrote: >With adaptive locking: >RESULT : tst_QMutex::contendedQMutex():"no msleep, 2 mutexes": > 1,961,622.638 CPU ticks per iteration > 5561.854224 task-clock # 3.781 CPUs utilized > > 17,706,600,180 cycles # 3.184 GHz > > 13,209,273,979 instructions # 0.75 insns per cycle > > 8,072,609 raw_syscalls:sys_enter # 1.451 M/sec > > 1.471046980 seconds time elapsed > >Adaptive locking is a busy-wait spin ahead of the sleep, iterating 1000 >times >trying to acquire the mutex. The Qt 4 solution was time based, whereas >the one >I'm implementing is a fixed number of cycles. It's similar to Glibc's >solution, >which is also a number of cycles. > >Note that the "without adaptive locking" solution still tries to acquire >it >once again. Without that, the results are much, much worse. I decided >that >trying once was an acceptable comparison because Olivier's original does >try >to lock once before trying to sleep. > >In *this* particular case, it runs in less time and with less CPU time, >but in >other cases it's not the same. In the msleep(2) case, it runs in similar >time >as pthread, but it uses roughly 33% more CPU. > >Conclusion: the biggest gain is the adaptive locking, even though it >introduces a busy-wait. I'd recommend keeping it and making it smarter, >really >*adapting* to how often the mutex is contended.
If we should "keep it", we first need to see it :) I couldn't find it in your changes list? -- .marius _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
