On sábado, 19 de maio de 2012 18.34.30, Olivier Goffart wrote: > Hi, > > Regarding valgrind: > *) On debug build, nothing is inlined. > *) If we keep it inline, then we would just need a patch like this [1]
-fno-inline doesn't help because of -fvisibility-inlines-hidden. The call
cannot be rerouted to valgrind.
The annotation you added might help, but as I said, adding instructions --
even if they produce no architectural change -- still consumes CPU resources.
I'd like to benchmark the annotation vs the function call.
>
> Regarding Transactional memory:
> *) Very interesting
> *) Notice the end of section 8.2.1: "Improper use of hints will not cause
> functional bugs though it may expose latent bugs already in the code.".
> So in other words, we can use XAQUIRE and XRELEASE without any problem
> in inline code, without binary compaibility issue
Indeed, but note that what it says about transactions that abort too often. If
the transaction aborts, then the code needs to be re-run non-transactionally,
with the lock. That means decreased performance and increased power
consumption.
Note also that all x87 instructions will abort, so any transactions around x87
code (32-bit floating point) would cause aborts.
At this point, we don't know which mutex locks we should make transactional.
As I said, neither you nor I have a Haswell prototype to test on. At the
earliest, we'll be able to test this for Qt 5.2.
> *) The other transactional model does not really apply, but even if it
> would, we could still use some different value for locked and unlocked and
> the previously inline code falls back to the non-inline code.
RTM might apply because we can get extra information about the abort and figure
out whether that particular lock should use transactions the next time.
> *) debugging tools (valgrind) could also detect the XAQUIRE and XRELEASE
> prefix.
>
> Regarding increasing the size
> *) I think it is valuable to have small memory overhead per mutexes.
> *) I think recursive mutex don't deserve improvements on the detriment of
> normal ones
> *) I think there would not be improvement on Windows.
If we don't improve for recursive mutexes and I simply don't try Windows or
Mac, then there's no need to increase the mutex size.
Then I need only to look into QReadWriteLock.
--
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 Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
