<div dir="ltr"><div dir="ltr"><div>Hi Kevin,</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Would this introduce start-up latency based on the size of the compilation? JIT jobs with 100-200MB of source are not uncommon here, and I’d hate to see latency get much worse.</blockquote><div dir="ltr"><br></div><div>Short answer: I don't see this adding measurable latency for your use case.</div><div><br></div><div>Longer answer:</div><div><br></div><div>I think the runtime will be non-mandatory: If you're not going to use any of the features you could opt out of loading it, in which case there will be no overhead at all.</div><div><br></div><div>If you load the runtime but don't use it you will pay a small cost each time a lookup traverses the StaticLibraryDefinitionGenerator for the runtime. The cost would be one virtual call, plus N * DenseMap<uintptr_t> lookup. You can almost certainly arrange your libraries so that this cost is never paid in practice (by making the runtime the last thing searched).</div><div><br></div><div>The first time each feature (laziness, thread locals, dlfcn call, etc.) is used the JIT will load and link the corresponding part of the library. This will involve jit-linking a few kilobytes of pre-compiled code  at most, and happens only once per feature per session.</div><div><br></div><div>I don't think any of this will be measurable against the cost of compiling any source files, let alone tens or hundreds of Mb worth.</div><div><br></div><div>Are you using the concurrent compilation feature on Orc? If you're seeing high startup latency on multicore machines that may offer a way to reduce it.</div><div><br></div><div>-- Lang. </div><div><br></div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 21, 2021 at 8:48 AM Kevin Neal via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">





<div lang="EN-US" style="word-wrap:break-word">
<div class="gmail-m_2848065246781099106WordSection1">
<p class="MsoNormal"><span style="font-family:"Courier New";color:rgb(68,84,106)">Would this introduce start-up latency based on the size of the compilation? JIT jobs with 100-200MB of source are not uncommon here, and I’d hate to see latency get much worse.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New";color:rgb(68,84,106)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New";color:rgb(68,84,106)">A small enough fixed latency would be ok.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10pt;font-family:"Courier New";color:rgb(68,84,106)">--</span><span style="color:rgb(68,84,106)">
<br>
</span><span style="font-size:10pt;font-family:"Courier New";color:rgb(68,84,106)">Kevin P. Neal</span><span style="color:rgb(68,84,106)"><br>
</span><span style="font-size:10pt;font-family:"Courier New";color:rgb(68,84,106)">SAS/C and SAS/C++ Compiler<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10pt;font-family:"Courier New";color:rgb(68,84,106)">Compute Services<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10pt;font-family:"Courier New";color:rgb(68,84,106)">SAS Institute, Inc.</span><span style="color:rgb(68,84,106)"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New";color:rgb(68,84,106)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New";color:rgb(68,84,106)"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New";color:rgb(68,84,106)"><u></u> <u></u></span></p>
<div>
<div style="border-style:solid none none;border-top-width:1pt;border-top-color:rgb(225,225,225);padding:3pt 0in 0in">
<p class="MsoNormal"><b>From:</b> llvm-dev <<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.org</a>> <b>On Behalf Of
</b>Lang Hames via llvm-dev<br>
<b>Sent:</b> Tuesday, January 19, 2021 5:09 PM<br>
<b>To:</b> Stefan Gränitz <<a href="mailto:stefan.graenitz@gmail.com" target="_blank">stefan.graenitz@gmail.com</a>><br>
<b>Cc:</b> Vivien Millet <<a href="mailto:vivien.millet@gmail.com" target="_blank">vivien.millet@gmail.com</a>>; Athul Acharya <<a href="mailto:aacharya@gmail.com" target="_blank">aacharya@gmail.com</a>>; LLVM Developers Mailing List <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>; kris <<a href="mailto:cq.personal@gmail.com" target="_blank">cq.personal@gmail.com</a>>; Jared Wyles <<a href="mailto:jared.wyles@gmail.com" target="_blank">jared.wyles@gmail.com</a>>; Frances Mocnik <<a href="mailto:fmocnik@gmail.com" target="_blank">fmocnik@gmail.com</a>>; Jacob Lifshay
 <<a href="mailto:programmerjake@gmail.com" target="_blank">programmerjake@gmail.com</a>>; Christian Schafmeister <<a href="mailto:meister@temple.edu" target="_blank">meister@temple.edu</a>><br>
<b>Subject:</b> Re: [llvm-dev] LLVM Orc Weekly #28 -- ORC Runtime Prototype update<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<p><b><i><span style="font-size:12pt;font-family:Arial,sans-serif;color:red">EXTERNAL</span></i></b><span style="font-size:12pt;font-family:Arial,sans-serif;color:red">
</span><u></u><u></u></p>
<div>
<div>
<div>
<div>
<p class="MsoNormal">Big question for JIT clients: Does anyone have any objection to APIs in ORC *relying* on the runtime being loaded in the target? If so, now is the time to let me know. :)<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I think possible objections are JIT'd program startup time (unlikely to be very high, and likely fixable via careful runtime design and pre-linking of parts of the runtime), and difficulties building compiler-rt (which sounds like something
 we should fix in compiler-rt).<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">If we can assume that the runtime is loadable then we can significantly simplify the TargetProcess library, and TargetProcessControl API, and further accelerate feature development in LLVM 13.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">-- Lang.<u></u><u></u></p>
</div>
</div>
</div>
<div>
<blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<pre><u></u> <u></u></pre>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
</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="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div></div>