<div dir="ltr">Hi Lang,<div><br></div><div>Thanks for the link. I will study it.</div><div><br></div><div>So just for my understanding. When you say ORC is a super set of MCJiT, it means that ORC also support object caching right ?</div><div><br></div><div>My application is a calculation model environment. There's a library of calculations that are user defined and pre-compiled. A typical calculation can consist of a couple of millions statements. So they are quite "big". Users can input/override values and trigger calculations. (consider it as a really really big excel sheet).</div><div><br></div><div>My Ideal situation would be something like:</div><div><br></div><div>1. seed model with cached objects</div><div>2. for every set of statements associated with a module. Add the module</div><div>3. Jit and remove the module, save the function ptr outside, for invocation.</div><div><br></div><div>But there's like 10% of variable code that can invoke previous defined functions in the modules. So I could not remove the module after jit right? The IR probably needs to be kept alive right?</div><div>When I tried this with MCJiT, my address seems to be invalid after remove module, does ORC works differently in this case?</div><div><br></div><div>During runtime, JiT time is quite important, so during runtime, no optimization is applied to speed up JIT time. Are there other "tricks" that can be applied to speed up JIT speed?</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 2, 2016 at 12:57 AM, Lang Hames <span dir="ltr"><<a href="mailto:lhames@gmail.com" target="_blank">lhames@gmail.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">Hi Koffie,<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"><span style="font-size:12.800000190734863px">I'm at nearing release deadline, so switching at this time is probably not a good idea. Unless Orc and MCJit are almost api compatible. Are there any docs available for making the transition ?</span></blockquote><div><span style="font-size:12.800000190734863px"><br></span></div></span><div><span style="font-size:12.800000190734863px">Orc's functionality is a superset of MCJIT's and it's generally an easy transition, however they're not API compatible: ORC doesn't derive from ExecutionEngine. If/when you want to try porting your code I would recommend checking out the new tutorial series <a href="http://llvm.org/docs/tutorial/BuildingAJIT1.html" target="_blank">http://llvm.org/docs/tutorial/BuildingAJIT1.html</a> . There are also C bindings for the new API (</span><a href="http://llvm.org/docs/doxygen/html/OrcBindings_8h.html" target="_blank">http://llvm.org/docs/doxygen/html/OrcBindings_8h.html</a>) but it sounds like you're happy with the C++ API.</div><span class=""><div><span style="font-size:12.800000190734863px"><br></span></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">With regards to the multiple ExecutionEngine: I have a runtime that can accept code that is known in advance (about 90% of the code). I'm able to cache the object to reduce jit time. For now I'm using one execution engine with multiple modules.<br><span style="font-size:12.800000190734863px">What benefits would I gain with an execution engine per module ? I think this will be harder and more memory expensive, since code from different module can invoke each other.</span></blockquote><div><span style="font-size:12.800000190734863px"><br></span></div></span><div><span style="font-size:12.800000190734863px">Some use-cases require multiple engines, but if yours doesn't I see no advantage in switching unless you use a different memory manager for each engine: If you use a different memory for each engine you can discard individual engines after you're done with them, freeing the underlying memory.</span></div><span class=""><div><span style="font-size:12.800000190734863px"><br></span></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"><span style="font-size:12.800000190734863px">So MCJit is known for keeping memory used I assume (relocatable objects)? I will try to figure out which part of MCJiT is using the memory. Any pointers to keep at the back of my head during this ?</span></blockquote><div><span style="font-size:12.800000190734863px"><br></span></div></span><div><span style="font-size:12.800000190734863px">MCJIT keeps the relocatable objects alive, yes. It will also keep the IR alive unless you explicitly remove it using removeModule.</span></div><div><br></div><div><span style="font-size:12.800000190734863px">You might be able to figure out a way to deallocate the objects by adding new API, but I'd recommend putting that effort into porting to ORC instead - you'll get the memory benefits natively, plus the new features that are in the works.</span></div><span class="HOEnZb"><font color="#888888"><div><br></div><div><span style="font-size:12.800000190734863px">- Lang.</span></div><div><span style="font-size:12.800000190734863px"><br></span></div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 1, 2016 at 1:53 PM, koffie drinker <span dir="ltr"><<a href="mailto:gekkekoe@gmail.com" target="_blank">gekkekoe@gmail.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">Hi Lang,<div><br></div><div>I'm at nearing release deadline, so switching at this time is probably not a good idea. Unless Orc and MCJit are almost api compatible. Are there any docs available for making the transition ?</div><div><br></div><div>With regards to the multiple ExecutionEngine: I have a runtime that can accept code that is known in advance (about 90% of the code). I'm able to cache the object to reduce jit time. For now I'm using one execution engine with multiple modules.</div><div><br></div><div>What benefits would I gain with an execution engine per module ? I think this will be harder and more memory expensive, since code from different module can invoke each other.</div><div><br></div><div>So MCJit is known for keeping memory used I assume (relocatable objects)? I will try to figure out which part of MCJiT is using the memory. Any pointers to keep at the back of my head during this ?</div><div><br></div><div><br></div><div><br></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 29, 2016 at 11:51 PM, Lang Hames <span dir="ltr"><<a href="mailto:lhames@gmail.com" target="_blank">lhames@gmail.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">Hi Koffie,<div><br></div><div>I'd highly recommend switching to ORC from MCJIT. It is much more flexible when it comes to memory-management.</div><span><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"><span style="font-size:12.800000190734863px">1. I took the approach of 1 execution engine with multiple modules (I'm not removing modules once they have been added). During profiling, I noticed that the memory usage is high with a lot of code. How can I reduce the memory usage? Is one execution engine per module preferred? I would imagine that this would take up more memory.</span></blockquote><div><span style="font-size:12.800000190734863px"><br></span></div></span><div><span style="font-size:12.800000190734863px">Whether or not you need multiple ExecutionEngines depends on your use case, but for non-trivial use-cases yes: One ExecutionEngine per Module seems to be required.</span></div><span><div><span style="font-size:12.800000190734863px"><br></span></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"><span style="font-size:12.800000190734863px">2. When I add a module and jit it, can I invoke a remove module and still be able to execute the compiled function?</span></blockquote><div><span style="font-size:12.800000190734863px"><br></span></div></span><div><span style="font-size:12.800000190734863px">You can remove the module using ExecutionEngine::removeModule(M), but be aware that this will clear the global mappings associated with the Module, so any interfaces that use IR will no longer function.</span></div><span><div><span style="font-size:12.800000190734863px"><br></span></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"><span style="font-size:12.800000190734863px">3. Is it better to have one runtime mem manager that will be associated with multiple execution engines (one engine per module)? Using this approach I could throw away the execution engines once they have jitted the code. I probably need to take ownership of the jitted code somehow. Are there any examples available on how this could be achieved?</span></blockquote><div><br></div></span><div>The MemoryManager owns the JIT'd code. As long as it is alive the code will hang around. You will need to keep the symbol mappings if you need them.</div><div><br></div><div><br></div><div>If you switch to ORC this tends to be easier: You have one stack and can add as many modules to it as you like. The type of Module pointer that you add determines the ownership semantics: Pass a raw pointer and the JIT does not take ownership. Pass a std::unique_ptr<Module> and the JIT does own the IR. Pass a shared_ptr<Module> and it's shared. The JIT will release the IR as soon as it is able to.</div><div><br></div><div>ORC also frees the relocatable objects as soon as possible (which MCJIT does not do), so it's likely to have better memory performance over all.</div><span><font color="#888888"><div><br></div><div>- Lang.</div><div><span style="font-size:12.800000190734863px"><br></span></div></font></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 25, 2016 at 8:07 AM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.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">+Lang for JIT things.<br><br><div class="gmail_quote"><div><div><div dir="ltr">On Sun, Jul 24, 2016 at 8:50 AM koffie drinker via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr">Hi all,<div><br></div><div>I'm building a runtime that  can jit and execute code. I've followed the kaleidoscope tutorial and had a couple of questions. Basically I have a pre-compiler that compiles the code to cache objects. These cached objects are then persisted  and used to reduce Jit compile time.</div><div><br></div><div>1. I took the approach of 1 execution engine with multiple modules (I'm not removing modules once they have been added). During profiling, I noticed that the memory usage is high with a lot of code. How can I reduce the memory usage? Is one execution engine per module preferred? I would imagine that this would take up more memory.</div><div><br></div><div>2. When I add a module and jit it, can I invoke a remove module and still be able to execute the compiled function?</div><div><br></div><div>3. Is it better to have one runtime mem manager that will be associated with multiple execution engines (one engine per module)? Using this approach I could throw away the execution engines once they have jitted the code. I probably need to take ownership of the jitted code somehow. Are there any examples available on how this could be achieved?</div><div><br></div><div>cheers,</div><div><br></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="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>
</blockquote></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>