[FoRK] C++11 / STL, Re: Raspberry Pi + Qt5 + OpenGL = awesome

J. Andrew Rogers andrew at jarbox.org
Fri Apr 12 17:39:55 PDT 2013


On Apr 12, 2013, at 2:54 PM, Stephen Williams <sdw at lig.net> wrote:
> 
> Too slow even with move semantics rewrite?


Many pre-C++11 compilers already implemented some of those move optimizations implicitly. It is a micro-optimization in any case. The STL does not offer enough knobs for most non-trivial constructs to not hardwire use case assumptions that will generate poor performance some of the time.


>> We have our own pure C++11 implementations of things most programmers would use the STL for but we usually tried to use the STL first.
> 
> Do you remember a specific example?


Container allocators in the current implementation are widely broken. We've replaced various map-like STL containers with much faster alternatives. It has been a while since I've (officially) written code but those are two that immediately come to mind.


> Why not fix the GNU libc++ STL instead of starting over?


Starting over or designing specifically what we need is easier than fixing GCC's STL. Also, a standards compliant fix would really just break things for someone else. 


>> Nah, we just use the native Linux interfaces. Much better and cleaner, and without unnecessary threads.
>> 
> Sure, and if that is your only target, perfect.


Practical economics make Linux our only officially supported server-side target, which conveniently matches demand.

Portability is expensive if performance matters. On UNIX-like server environments, the difference in performance between portable and non-portable implementations is on the rough scale of 3x these days and getting worse. It is possible to integrate the non-portable APIs of multiple systems into a code base but that adds a substantial amount of complexity to the code and testing. Worse, in a handful of cases portability requires writing assembly code. Along that trend, I see a growing number of quasi-portable open source libraries that only support little endian architectures. 





More information about the FoRK mailing list