[Development] Use of Standard Library containers in Qt source code
Marc Mutz
marc.mutz at kdab.com
Thu Jul 7 11:36:57 CEST 2016
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
More information about the Development
mailing list