<div dir="ltr">With a 4 second difference between best and worst runs in both cases, and only 0.2 second difference between the best for the two different cases (user time), I don't think you can make any conclusion that one is better than the other! They are very very similar.</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 18, 2015 at 5:36 PM, Davide Italiano <span dir="ltr"><<a href="mailto:davide@freebsd.org" target="_blank">davide@freebsd.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Mar 16, 2015 at 11:00 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br>
><br>
><br>
> On Mon, Mar 16, 2015 at 10:52 PM, Davide Italiano <<a href="mailto:davide@freebsd.org">davide@freebsd.org</a>><br>
> wrote:<br>
>><br>
>> On Mon, Mar 16, 2015 at 1:54 AM, Davide Italiano <<a href="mailto:davide@freebsd.org">davide@freebsd.org</a>><br>
>> wrote:<br>
>> ><br>
>> > Shankar's parallel for per-se didn't introduce any performance benefit<br>
>> > (or regression).<br>
>> > If the change I propose is safe, I would like to see Shankar's change<br>
>> > in (and this on top of it).<br>
>> > I have other related changes coming next, but I would like to tackle<br>
>> > them one at a time.<br>
>> ><br>
>><br>
>> Here's an update.<br>
>><br>
>> After <a href="http://reviews.llvm.org/D8372" target="_blank">http://reviews.llvm.org/D8372</a> , I updated the profiling data.<br>
>><br>
>> <a href="https://people.freebsd.org/~davide/llvm/lld-03162015.svg" target="_blank">https://people.freebsd.org/~davide/llvm/lld-03162015.svg</a><br>
>> It seems now 85% of CPU time is spent inside<br>
>> FileArchive::buildTableOfContents().<br>
>> In particular, 35% of the samples are spent inserting into<br>
>> unordered_map, so there's maybe something we can do differently there<br>
>> (e.g. , Rui's proposal of a concurrent map doesn't seem that bad).<br>
><br>
><br>
> Anyone tried a DenseMap instead of an unordered_map? If you need pointer<br>
> validity to the elements, a DenseMap with unique_ptrs rather than direct<br>
> values could be an option. Chandler's usual argument here is that walking<br>
> the map is cheap with high locality (as in a DenseMap) even if the nodes<br>
> themselves involve indirection. Could be worth an experiment.<br>
><br>
<br>
</span>I did now. It actually makes things slower for the aforementioned<br>
workload (linking clang). It was worth trying though.<br>
<br>
Patch, in case somebody wants to try at home:<br>
<a href="https://people.freebsd.org/~davide/llvm/densemap_membermap.diff" target="_blank">https://people.freebsd.org/~davide/llvm/densemap_membermap.diff</a><br>
<br>
Patched:<br>
real    1m27.849s  user    2m47.373s   sys     0m16.370s<br>
real    1m29.583s  user    2m47.771s   sys     0m16.816s<br>
real    1m25.956s  user    2m43.397s   sys     0m15.254s<br>
real    1m29.380s  user    2m47.618s   sys     0m15.386s<br>
real    1m25.426s  user    2m43.388s   sys     0m16.961s<br>
<br>
Unpatched:<br>
real    1m26.872s  user    2m46.999s sys     0m16.540s<br>
real    1m28.187s  user    2m47.084s sys     0m17.149s<br>
real    1m24.814s  user    2m43.311s  sys     0m16.979s<br>
real    1m25.011s  user    2m43.184s  sys     0m16.975s<br>
real    1m25.536s  user    2m44.577s  sys     0m16.784s<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Davide<br>
<br>
"There are no solved problems; there are only problems that are more<br>
or less solved" -- Henri Poincare<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br></div>