[Development] To "inline" or not (Was " Mutex future directions")

[Atlant Schmidt]

Folks:

  There's been a lot of discussion recently regarding whether
  or not Qt functions (specifically, interlocking functions)
  should be declared "inline" or not.

  But in fact, isn't this much ado about nothing? If I
  understand current compiler technology, when one declares
  a function "inline", that's nothing more than a hint to
  the compiler. (At least at high optimization settings),
  the compiler can choose to ignore you and compile your
  function as an ordinary out-of-line function. It can also
  chose to elevate any ordinary function to inline if it
  chooses. (Isn't "tail-folding" a common example of this?)

  We can discuss this 'til the cows come home, but nowadays,
  how much control can we really assert / do we really want
  to assert over this?

  Aren't we supposed to be Relegating the Important Stuff
  to the Compilers?

                             Atlant

-----Original Message-----
From: development-bounces+aschmidt=dekaresearch.com at qt-project.org [mailto:development-bounces+aschmidt=dekaresearch.com at qt-project.org] On Behalf Of bradley.hughes at nokia.com
Sent: Tuesday, May 22, 2012 03:12
To: thiago.macieira at intel.com; lars.knoll at nokia.com
Cc: development at qt-project.org
Subject: Re: [Development] Mutex future directions


On May 21, 2012, at 2:58 PM, ext Thiago Macieira wrote:

> On segunda-feira, 21 de maio de 2012 08.34.32, bradley.hughes at nokia.com wrote:
>> On May 18, 2012, at 8:34 PM, ext Thiago Macieira wrote:
>>> Recommendations (priority):
>>>
>>> (P0) de-inline QBasicMutex locking functions until we solve some or all of
>>> the below problems
>>
>> I agree with this, so that it gives a chance to fix the performance
>> regressions on Mac at a later date (since it probably won't be fixed before
>> 5.0 is released).
>
> Some notes from the IRC discussion this morning between Olivier, Brad and
> myself:
>
> * QMutex contended performance has dropped considerably on Mac from 4.8 to
> 5.0 (it's 10x slower)
> * QMutex contended performance on Mac is now actually similar to the
> pthread_mutex_t performance (read: contended QMutex on 4.8 is 10x faster than
> pthread_mutex_t)
> * changing the QMutex implementation to use the generic Unix codepath on Mac
> makes it 2x slower
> * the non-Linux code in QBasicMutex::lockInternal is considered complex and
> hard to read by both Brad and myself
>
> Brad: could you please provide what is, to the best of your knowledge today,
> the combination of tricks that made 4.8 fast?

The trick was the adaptive spin, added and modified over a series of commits in 4.8. The biggest gain was on Mac, Linux performance didn't change noticibly, Windows did get a small gain too (as far as I recall).

> * QMutex de-inlining and the Mac performance issues are orthogonal.
> * QMutex "de-inlining" should be understood more correctly as: removing the
> testAndSet calls from the inline functions. The inline functions should remain
> inline.
> * The de-inlining is important for Valgrind (helgrind / DRD) to work
> properly, even in release mode

Lars and I had a conversation in the hallway about how QMutex performance on Windows. It's been a while since I last tested, but I recall that QMutex didn't out perform CRITICAL_SECTIONs. De-inlining is necessary so that we can make QMutex nothing more than a wrapper around CRITICAL_SECTION (since the latter performs better).

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).

> Note that there's another trick that QMutex can apply under valgrind but
> QBasicMutex cannot: if the QMutex constructor initialises the d pointer to
> anything non-null and different from 3, the inlined testAndSet will fail, so
> valgrind can properly hijack the lock and unlock functions.
>
> --
> 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
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

--
Bradley T. Hughes
bradley.hughes at nokia.com


This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message.

Thank you.

Please consider the environment before printing this email.