<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Feb 28, 2016 at 12:13 AM, Xinliang David Li <span dir="ltr"><<a href="mailto:davidxl@google.com" target="_blank">davidxl@google.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 class="gmail_extra"><br><div class="gmail_quote"><span class="">On Sat, Feb 27, 2016 at 6:50 PM, Sean Silva <span dir="ltr"><<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</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"><div dir="ltr">I have thought about this issue too, in the context of games. We may want to turn profiling only for certain frames (essentially, this is many small profile runs).<div><br></div><div>However, I have not seen it demonstrated that this kind of refined data collection will actually improve PGO results in practice.</div><div>The evidence I do have though is that IIRC Apple have found that almost all of the benefits of PGO for the Clang binary can be gotten with a handful of training runs of Clang. Are your findings different?</div></div></blockquote><div><br></div></span><div>We have a very wide customer base so we can not claim one use model is sufficient for all users. For instance, we have users using fine grained profile dumping control (programatically) as you described above. There are also other possible use cases such as dump profiles for different periodical phases into files associated with phases. Later different phase's profile data can be merged with different weights.</div><span class=""><div> <br></div><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"><div dir="ltr"><div><br></div><div>Also, in general, I am very wary of file locking. This can cause huge amounts of slowdown for a build and has potential portability problems. </div></div></blockquote><div><br></div></span><div>I don't see much slow down with a clang build using instrumented clang as the build compiler. With file locking and profile merging enabled, the build time on my local machine looks like:</div><div><br></div><div><div>real    18m22.737s</div><div>user    293m18.924s</div><div>sys     9m55.532s</div></div><div><br></div><div>If profile merging/locking is disabled (i.e, let the profile dumper to clobber/write over each other),  the real time is about 14m.  </div><span class=""><div> <br></div><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"><div dir="ltr"><div>I don't see it as a substantially better solution than wrapping clang in a script that runs clang and then just calls llvm-profdata to do the merging. Running llvm-profdata is cheap compared to doing locking in a highly parallel situation like a build.</div></div></blockquote><div><br></div></span><div>That would require synchronization for merging too. </div><div><br></div><div>>From Justin's email, it looks like there is a key point I have not made clear: the on-line profile merge is a very simple raw profile to raw profile merging which is super fast. The end result of the profile run is still in raw format. The raw to indexed merging is still needed -- but instead of merging thousands of raw profiles which can be very slow, with this model, only one raw profile input is needed.</div></div></div></div></blockquote><div><br></div><div>I think that __llvm_profile_merge_buffers in the runtime would be a useful primitive if it can be implemented simply (or __llvm_profile_load_counters_from_buffer, perhaps). If you could post a patch for that part as a first incremental step that would be a good starting point for concrete discussion.</div><div><br></div><div>In combination with the buffer API and reset_counters this is all that is needed for very fine-grained counter capture.</div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>thanks,</div><div><br></div><div>David</div><span class=""><div> </div><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"><div dir="ltr"><div><br></div><div><div><br></div><div>-- Sean Silva</div></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Sat, Feb 27, 2016 at 6:02 PM, Xinliang David Li 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div><div dir="ltr">One of the main missing features in Clang/LLVM profile runtime is the lack of support for online/in-process profile merging support. Profile data collected for different workloads for the same executable binary need to be collected and merged later by the offline post-processing tool.  This limitation makes it hard to handle cases where the instrumented binary needs to be run with large number of small workloads, possibly in parallel.  For instance, to do PGO for clang, we may choose to  build  a large project with the instrumented Clang binary. This is because<div> 1) to avoid profile from different runs from overriding others, %p substitution needs to be specified in either the command line or an environment variable so that different process can dump profile data into its own file named using pid. This will create huge requirement on the disk storage. For instance, clang's raw profile size is typically 80M -- if the instrumented clang is used to build a medium to large size project (such as clang itself), profile data can easily use up hundreds of Gig bytes of local storage. </div><div>2) pid can also be recycled. This means that some of the profile data may be overridden without being noticed.</div><div><br></div><div>The way to solve this problem is to allow profile data to be merged in process.  I have a prototype implementation and plan to send it out for review soon after some clean ups. By default, the profiling merging is off and it can be turned on with an user option or via an environment variable. The following summarizes the issues involved in adding this feature:</div><div> 1. the target platform needs to have file locking support</div><div> 2. there needs an efficient way to identify the profile data and associate it with the binary using binary/profdata signature;</div><div> 3. Currently without merging, profile data from shared libraries (including dlopen/dlcose ones) are concatenated into the primary profile file. This can complicate matters, as the merger also needs to find the matching shared libs, and the merger also needs to avoid unnecessary data movement/copy;</div><div> 4. value profile data is variable in length even for the same binary.</div><div><br></div><div>All the above issues are resolved and clang self build with instrumented binary passes (with both j1 and high parallelism). </div><div><br></div><div>If you have any concerns, please let me know.</div><div><br></div><div>thanks,</div><div><br></div><div>David</div><div><br></div></div>
<br></div></div>_______________________________________________<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/mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div>
</blockquote></span></div><br></div></div>
</blockquote></div><br></div></div>