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

Stephen Williams sdw at lig.net
Fri Apr 12 19:00:04 PDT 2013


On 4/12/13 5:39 PM, J. Andrew Rogers wrote:
> 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.

A) I don't see how that's possible besides return value optimization.  B) Move semantics (and by implication rvalue references) 
solve the main performance problem with C++ and template libraries, extra temporary objects created all over, so I don't see how 
it is a micro-optimization.

http://www.cprogramming.com/c++11/rvalue-references-and-move-semantics-in-c++11.html
> The entire contents of new_values must be copied! In principle, there could be up to two copies here: one into a temporary 
> object to be returned, and a second when the vector assignment operator runs on the line v = doubleValues( v );. The first 
> copy may be optimized away by the compiler automatically, but there is no avoiding that the assignment to v will have to copy 
> all the values again, which requires a new memory allocation and another iteration over the entire vector.

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

While I see how container allocators could be useful, and I've used that kind of mechanism sometimes, it isn't that helpful most 
of the time.
I might end up using something like that soon for a thread/job system, although the need to be able to selectively use ION 
buffers is going to complicate things.
I have a hard time finding comments bout missing allocator features in current-version libraries.

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

sdw



More information about the FoRK mailing list