<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Wed, Oct 19, 2016 at 10:06 PM, David Jones <span dir="ltr"><<a href="mailto:djones@xtreme-eda.com" target="_blank">djones@xtreme-eda.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>Out of curiosity, when you did these tests, did you compile your test program with -O2?<br></div></div></div></div></blockquote><div><br></div><div>The test program, or llvm?</div><div><br></div><div>llvm was the standard llvm installed by Ubuntu's package manager. I expect it's compiled with some nonzero -O level</div><div><br></div><div>I think I compiled my test program without optimization. That will change the amount of work llvm does, but I think not the nature of it.</div><div><br></div><div>I'm happy to do more tests.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div> <br></div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div></div>I am working on a large codebase that uses intrusive reference counting. I'm finding that without -O (e.g. build for easy debug) it's quite slow, but with -O2 it's maybe 4x faster. This indicates that optimization can clean up a lot of the overhead of reference counting.<br><br></div>Whether or not a GC such as BDWGC can help you depends on how much "memory churn" your program does. Again, I've found that my software tends to allocate and free quite a lot of memory, so if I used GC, then I'd spend 25%+ time doing the GC. On the other hand, if you do more computing than allocating, then you may come out ahead - GC has zero overhead when not actually allocating, whereas reference-counting can have overhead when traversing a data structure even if you malloc/free nothing.<br><br></div>As always, the particular application is what matters, and your mileage may vary.<br><br></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Wed, Oct 19, 2016 at 2:14 PM, Bruce Hoult via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Oct 19, 2016 at 6:24 PM, Benjamin Kramer via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">In terms of performance shared_ptr has a number of disadvantages. One<br>
is that it always uses atomics even though most IntrusiveRefCntPtrs<br>
are used in single-threaded contexts. Another is weak_ptr adding a lot<br>
of complexity to the implementation, IntrusiveRefCntPtr doesn't<br>
support weak references.<br>
<br>
With that it's hard to make a case for changing uses of<br>
IntrusiveRefCntPtr as it's a non-trivial amount of work<br>
(IntrusiveRefCntPtr binds the reference count to the object itself,<br>
shared_ptr doesn't. Figuring out when a value held by an<br>
IntrusiveRefCntPtr is passed around by raw pointer and stuffed into<br>
another IntrusiveRefCntPtr is hard) with potential negative<br>
performance impact.<br>
<div class="m_2589260064464505019m_-3526889660651902978gmail-HOEnZb"><div class="m_2589260064464505019m_-3526889660651902978gmail-h5"><span style="color:rgb(34,34,34)"></span></div></div></blockquote><div> </div><div>In terms of performance, the whole concept has a number of disavantages :-)</div><div><br></div><div>I recently tried an experiment. I compiled a 40000 line C file (concatenated all the files of a project together) to .bc with clang, and then ran llc on it. I tried it on both Ubuntu 16.04 x64 and on an Odroid XU-4 ARM board. with very similar results.</div><div><br></div><div>I made a tiny library with a 1 GB static char array. I made a malloc() that simply bumped a pointer (prepending a 32 bit object size, just for realloc(), grrrrrr kill it with fire), and a free() that is an empty function. There's a calloc() that calls the above malloc() and then memset(). And a realloc() that is a no-op if the size is smaller, or does malloc(), memcpy() if bigger.</div><div><br></div><div>Then I used LD_PRELOAD to replace the standard malloc library with mine.</div><div><br></div><div>Result: ~10% faster execution than llc without LD_PRELOAD, and ~180 MB of the array used (120 MB on the 32 bit ARM).</div><div><br></div><div>Then I built BDW GC as a malloc replacement (with free() as a no-op) and used LD_PRELOAD with it.</div><div><br></div><div>Result: ~20% faster execution than llc without LD_PRELOAD, and ~10 MB of RAM used.</div><div><br></div><div>In this experiment all the reference counting in IntrusiveRefCntPtr or shared_ptr or whatever still takes place, the same as before. But at the end, when it decides to call free, it's a no-op. So all the reference-counting machinery is a complete waste of time and code and RAM and the program would run strictly faster if it was ripped out.</div><div><br></div><div>I don't know for sure (it's a lot more work to try!), but I would not be surprised to see a further 10%-20% speedup.</div><div><br></div><div><br></div><div>And then you come to the cognitive load on the programmer, trying to decide whether to use IntrusiveRefCntPtr or shared_ptr or unique_ptr or auto_ptr or weak_ptr or whether and where to call free()/delete. And the extra typing needed to write it instead of using a raw pointer. And the extra time and cognitive load to read the code. And for what? </div><div><br></div></div></div></div>
<br></div></div><span class="">______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></span></blockquote></div><span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888">
<br>-- 
<br>This message has been scanned for viruses and
<br>dangerous content by
<a href="http://www.mailscanner.info/" target="_blank"><b>MailScanner</b></a>, and is
<br>believed to be clean.

</font></span></blockquote></div><br></div></div>