<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Nov 3, 2017 at 6:00 PM, Rafael Avila de Espindola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>One last thing I remembered. Most of the regression is because of massive branch mis prediction, which is not surprising in a hot binary search.<br>
<br>
In <a href="http://cglab.ca/~morin/misc/arraylayout-v2" target="_blank">http://cglab.ca/~morin/misc/<wbr>arraylayout-v2</a>/ there more efficient algorithms that don't need mis predicted branches.<br></div></blockquote><div><br></div><div>None of these algorithms can eliminate branch mis-predictions no? They might be have better memory locality, but but they don't seem to improve branch prediction.</div><div><br></div><div>I actually tried to implement the Eytzinger layout, but it didn't improve performance. You can see my patch here (<a href="https://github.com/rui314/llvm-project/commit/52ced61fe07e79b3c9307c013d0ec242bd67212c">https://github.com/rui314/llvm-project/commit/52ced61fe07e79b3c9307c013d0ec242bd67212c</a>) if you are interested.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
Last time I tried clang was creating more branches than expected, but that might be fixed now.<br>
<br>
Cheers,<br>
Rafael<br>
<br><br><div class="gmail_quote"><div><div class="gmail-h5">On November 3, 2017 1:21:42 PM PDT, Rafael Avila de Espindola <<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>> wrote:</div></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<pre class="gmail-m_-5460432745521583165k9mail"><div><div class="gmail-h5">I found a fascinating fact about what regressed and what improved with<br>the cache:<br><br>Testcases that are compiled by gcc and have debug info benefit<br>tremendously: scylla got 20% faster and mozilla 15%.<br><br>Tests without debug information benefited a bit.<br><br>The one test we have with clang debug info (clang-gdb-index) regressed a<br>bit (1.3%).<br><br>So there is some difference that causes gcc produced debug info to hit a<br>lot more relocations to a symbol in a merge section. Not sure what that<br>is.<br><br>Cheers,<br>Rafael<br><br>Rui Ueyama via llvm-commits <<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>> writes:<br><br></div></div><blockquote class="gmail_quote" style="margin:0pt 0pt 1ex 0.8ex;border-left:1px solid rgb(114,159,207);padding-left:1ex"><div><div class="gmail-h5"> Author: ruiu<br> Date: Tue Oct 31 12:14:06 2017<br> New Revision: 317026<br><br> URL: <a href="http://llvm.org/viewvc/llvm-project?rev=317026&view=rev" target="_blank">http://llvm.org/viewvc/llvm-<wbr>project?rev=317026&view=rev</a><br> Log:<br> Revert r316305: Remove a fast lookup table from MergeInputSection.<br><br> This reverts commit r316305 because performance regression was observed.<br><br> Modified:<br> lld/trunk/ELF/InputSection.cpp<br> lld/trunk/ELF/InputSection.h<br><br> Modified: lld/trunk/ELF/InputSection.cpp<br> URL: <a href="http://llvm.org/viewvc/llvm-project/lld/trunk/ELF/InputSection.cpp?rev=317026&r1=317025&r2=317026&view=diff" target="_blank">http://llvm.org/viewvc/llvm-<wbr>project/lld/trunk/ELF/<wbr>InputSection.cpp?rev=317026&<wbr>r1=317025&r2=317026&view=diff</a><br></div></div><hr><div><div class="gmail-h5"><br> --- lld/trunk/ELF/InputSection.cpp (original)<br> +++ lld/trunk/ELF/InputSection.cpp Tue Oct 31 12:14:06 2017<br> @@ -968,9 +968,24 @@ uint64_t MergeInputSection::getOffset(<wbr>ui<br> if (!Live)<br> return 0;<br> <br> - const SectionPiece &Piece = *getSectionPiece(Offset);<br> + // Initialize OffsetMap lazily.<br> + llvm::call_once(InitOffsetMap, [&] {<br> + OffsetMap.reserve(Pieces.size(<wbr>));<br> + for (size_t I = 0; I < Pieces.size(); ++I)<br> + OffsetMap[Pieces[I].InputOff] = I;<br> + });<br> +<br> + // Find a string starting at a given offset.<br> + auto It = OffsetMap.find(Offset);<br> + if (It != OffsetMap.end())<br> + return Pieces[It->second].OutputOff;<br> +<br> + // If Offset is not at beginning of a section piece, it is not in the map.<br> + // In that case we need to search from the original section piece vector.<br> + const SectionPiece &Piece = *this->getSectionPiece(Offset)<wbr>;<br> if (!Piece.Live)<br> return 0;<br> +<br> uint64_t Addend = Offset - Piece.InputOff;<br> return Piece.OutputOff + Addend;<br> }<br><br> Modified: lld/trunk/ELF/InputSection.h<br> URL: <a href="http://llvm.org/viewvc/llvm-project/lld/trunk/ELF/InputSection.h?rev=317026&r1=317025&r2=317026&view=diff" target="_blank">http://llvm.org/viewvc/llvm-<wbr>project/lld/trunk/ELF/<wbr>InputSection.h?rev=317026&r1=<wbr>317025&r2=317026&view=diff</a><br></div></div><hr><span class="gmail-"><br> --- lld/trunk/ELF/InputSection.h (original)<br> +++ lld/trunk/ELF/InputSection.h Tue Oct 31 12:14:06 2017<br> @@ -263,6 +263,9 @@ private:<br> void splitStrings(ArrayRef<uint8_t> A, size_t Size);<br> void splitNonStrings(ArrayRef<<wbr>uint8_t> A, size_t Size);<br> <br> + mutable llvm::DenseMap<uint32_t, uint32_t> OffsetMap;<br> + mutable llvm::once_flag InitOffsetMap;<br> +<br> llvm::DenseSet<uint64_t> LiveOffsets;<br> };<br> <br><br><br><hr><br></span><span class="gmail-"> llvm-commits mailing list<br> <a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a><br> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-commits</a><br></span></blockquote></pre></blockquote></div><span class="gmail-HOEnZb"><font color="#888888"><br>
-- <br>
Sent from my Android device with K-9 Mail. Please excuse my brevity.</font></span></div></blockquote></div><br></div></div>