<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Jul 25, 2018 at 8:57 AM <<a href="mailto:aw1621107@gmail.com">aw1621107@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="m_-3748370816681265819WordSection1"><p class="MsoNormal" style="margin-right:0in;margin-bottom:12.0pt;margin-left:10.5pt">The number of lines of assembly isn't really a good proxy for the performance of some code - mostly due to inlining (one piece of code may be many more lines of assembly because it's not calling large/complicated external functions - or, even taken as a whole (including those external functions) it might still be more efficient to have longer code (because it's more specialized - ie: two calls to one generic function were inlined into two places and each one simplified/optimized a bit for those situations))<u></u><u></u></p></div></div><div lang="EN-US" link="blue" vlink="purple"><div class="m_-3748370816681265819WordSection1"><p class="MsoNormal">Yeah, you’re right; that was also pointed out to me by someone on one of the IRC channels I lurk on. A bit more investigation on Godbolt revealed that the difference could be to unrolling. It was certainly a surprise to me, as I expected that libstdc++ and libc++ would have relatively similar implementations that would produce relatively similar outputs. Guess something about libc++’s implementation is a bit easier for Clang to inspect? In any case, let that be a lesson to me to be a bit more careful about drawing conclusions from code size<u></u><u></u></p></div></div><div lang="EN-US" link="blue" vlink="purple"><div class="m_-3748370816681265819WordSection1"><p class="MsoNormal" style="margin-bottom:12.0pt"><br><br>That said, libc++ does have a bunch of forced inlining that's not for performance reasons, but for linkage reasons (to ensure that certain kinds of changes/updates to libc++ don't break existing compiled code/libraries). It's a tradeoff that not every user of libc++ needs to make & there are steps being taken to make that tradeoff more configurable/optional, so far as I understand it.<u></u><u></u></p></div></div><div lang="EN-US" link="blue" vlink="purple"><div class="m_-3748370816681265819WordSection1"><p class="MsoNormal">Huh, that’s interesting. That isn’t what is happening here, though, right? I didn’t see anything that looks like that around the declarations/implementations of emplace() and friends</p></div></div></blockquote><div><br>Yeah, probably doesn't come up for the fully dependent template things in the standard library - but maybe some implementation details that are used in there like allocators, etc, might have some of these features. There's a lot of stuff in there - so hard for me to check at a glance. (though you can see it around otehr functions in the form of _LIBCPP_INLINE_VISIBILITY)<br><br>- Dave<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="m_-3748370816681265819WordSection1"><p class="MsoNormal"><u></u><u></u></p></div></div><div lang="EN-US" link="blue" vlink="purple"><div class="m_-3748370816681265819WordSection1"><p class="MsoNormal"><u></u> <u></u></p><div><div><p class="MsoNormal">On Mon, Jul 23, 2018 at 4:43 PM via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<u></u><u></u></p></div><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt"><div><div><p class="MsoNormal">Hello all,<u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">Just a quick question to make sure I’m not missing something.<u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">This program:<u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal"><span style="font-family:Consolas">#include <vector></span><u></u><u></u></p><p class="MsoNormal"><span style="font-family:Consolas">void f(std::vector<double>& vec, double val) {</span><u></u><u></u></p><p class="MsoNormal"><span style="font-family:Consolas">      vals.emplace(std::cbegin(vec), val);</span><u></u><u></u></p><p class="MsoNormal"><span style="font-family:Consolas">}</span><u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">When compiled with trunk Clang on Godbolt with <span style="font-family:Consolas">-O3 -march=haswell -std=c++17 -stdlib=libstdc++</span>, 132 lines of assembly are produced. If <span style="font-family:Consolas">-stdlib=libc++</span> is used, though, 638 (!) lines of assembly are produced. A few of those lines are due to <span style="font-family:Consolas">f()</span> itself, but it appears the vast majority are due to the implementation of <span style="font-family:Consolas">emplace()</span>. As a partial comparison, GCC trunk produced 136 lines of assembly, and seems to have partially inlined <span style="font-family:Consolas">emplace()</span>, leaving 94 lines of assembly for <span style="font-family:Consolas">_M_realloc_insert</span>.<u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">I can sort of duplicate this on Debian sid, with libc++-dev 6.0.1-1 and <span style="font-family:Consolas">clang++-7</span> (<span style="font-family:Consolas">--version</span> doesn’t appear to give a revision number, unfortunately?). Using libstdc++ results in 176 lines of assembly, and libc++ results in 803 lines of assembly (counted by <span style="font-family:Consolas">wc -l</span>).<u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">Is this something to be worried about? I’m still rather new to performance-related work, so I’m working from a relatively simplistic view of what could be affecting performance. A 4x difference in what could be a commonly-used function seems rather unusual to me, though.<u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">Thanks,<u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">Alex<u></u><u></u></p></div></div><p class="MsoNormal">_______________________________________________<br>cfe-dev mailing list<br><a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><u></u><u></u></p></blockquote></div></div></div></blockquote></div></div>