
<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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.<div class=""><br class=""></div><div class="">- there is now small array optimization in the STL</div><div class="">- The usage of unsigned int (hello std::size_t) prevents so many optimizations. Vectorization could be one of them.</div><div class="">- std::unordered_map cannot be implemented with open addressing. Same for std::unordered_set</div><div class="">- 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</div><div class="">- 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.</div><div class="">- 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. ( <a href="http://en.cppreference.com/w/cpp/numeric/math/pow" class="">http://en.cppreference.com/w/cpp/numeric/math/pow</a> )</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""><div class="">

<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">François Fayard<br class=""></div></div>

</div>

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