On terça-feira, 22 de maio de 2012 07.12.26, [email protected] wrote: > So far, we've got 3 votes for de-inlining: Thiago, Lars, and myself. For the > few cases where inlining matters, we can inline inside Qt at those > locations (QMetaObject::activate() would be the first place to check).
Turns out that I got some unexpected extra ammo for this decision. Apparently,
some people from Intel found out about this thread and came to me to ask WTH I
was thinking. Fortunately, they also offered help :-)
We discussed a few ideas back and forth. Summarising:
- inlining the lock code should be done on a need-to-do basis, only where the
performance is really critical
- such inlined locks should or should not use Transactional Memory only after
we've done testing to ensure the performance
- for generic locks, the overhead of a function call is usually negligible
and will be drowned out by the rest of the work to be done
- for those generic locks, transactional memory use needs to be adaptative.
That means we need to use the RTM instructions, which require a CPUID check.
That check and the presence of the abort handler mean that we transactional
memory code would be non-inline.
- if we were to keep the inlined locking code, we'd need to change the
default value of QMutex's d pointer so that the inlined compare-and-swap
always fails. That means the code path for locking a mutex on x86 will always
include a *failed* compare-and-exchange on Haswell.
And I don't think they very much liked the idea of spinning while trying to
acquire a lock (consumes power)... at least we have a call to
QThread::yieldCurrentThread(), though it would be interesting to see what
happens if we replace it with a PAUSE instruction.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
