[Development] Use of Standard Library containers in Qt source code

[Marc Mutz]

On Thursday 07 July 2016 09:25:18 Martin Smith wrote:
> How about a merger of options 3 & 4 for Qt 6.0? A QtSTL that combines the
> ease of use of the Qt collections with the efficiency of STL algorithms.

Yes, for Qt 6, a template that takes an STL API and provides the Qt methods on 
it is something I'd welcome. But not to be required in internal 
implementation, as is implied in this thread. Game devs on CppCon report that 
compilers have problems fully inlining STL container use where it should be 
fully inlined (I myself ran into such a case: 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60621)

We use STL containers because they are more friendly to the compiler[1], which 
equates to faster and/or smaller, adding more stuff on top will make them 
slower, unless we fiddle with compiler-specific settings such as inlining 
depths, if that helps at all (it didn't for the bug report linked above).

Thanks,
Marc

[1] I don't think everyone here knows that every asm volatile as part of a 
QAtomic operation makes the compiler forget everything it knows about memory / 
value propagation, ie. it writes back registers to memory before and needs to 
re-load values from memory after the asm volatile. It gets better if QAtomic 
is backed by std::atomic, but even on x86, those ops aren't cheap. A cmpxchg 
takes more than 200 cycles to complete, if the memory is off-socket, compared 
to ≤ 0.5 cycles for a reg-reg operation. That's only the case if the object is 
actually shared among processors, but it shows just how bad it can be. On-die, 
it's still something like 20 cycles.


-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - Qt, C++ and OpenGL Experts