[llvm-dev] High Performance containers

[Francois Fayard via llvm-dev]

Thanks for your friendly comment. I agree that I was a bit rough with the STL. To be more specific, all those features can be performance issue in the STL. And I thought it was a given in the LLVM community.

- there is now small array optimization in the STL
- The usage of unsigned int (hello std::size_t) prevents so many optimizations. Vectorization could be one of them.
- std::unordered_map cannot be implemented with open addressing. Same for std::unordered_set
- Some API seems to be designed to shoot yourself in the foot performance wise, such as + for concatenating strings whereas an API such contact(s0, s1, …, sn) will never create temporaries
- Default initializations of elements in containers such as std::vector make it impossible to tune for NUMA architectures unless you really want to use custom allocators which will give you more pain than solutions.
- Mathematical functions such as std::pow are a joke. I am sure it does not affect STL people, but do you realize that the C++11 standard obliges the implementers to treat std::pow(x, 3) with x as a float with the following conversions : first convert x to double, then compute its cube, then convert it back to float. With C++03, the problem was not there. ( http://en.cppreference.com/w/cpp/numeric/math/pow )

The LLVM team seems to have done a great job reimplementing all those containers in a more efficient way which optimizations which are not at all specific to the STL. I am sure all the great idea you had could be useful to so many people in other field.

François Fayard

> On Aug 17, 2017, at 1:54 PM, Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> On Wed, Aug 16, 2017 at 12:24:33PM +0200, Francois Fayard via llvm-dev wrote:
>> Unfortunately, the C++ standard library suffers from its age and the
>> fact that it has never been thought for performance.
> 
> Just a friendly comment: opening remarks like that has a high chance to
> annoy people to just ignore the rest of the post. Claiming that STL
> design doesn't care about performance is not only ignorant, but
> blatantly false. One of the major contributions STL had from the
> beginning is requiring algorithmic complexity for many important
> algorithms. The specific implementation choices might not agree
> with your specific environment, but that doesn't mean they haven't been
> carefully made. That's exactly where many LLVM ADT entries came from: a
> specific problem with a big enough impact on the total design and/or
> runtime that can be optimized for those constraints.
> 
> Joerg
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170817/6bf19416/attachment.html>