preejackie via llvm-dev <llvm-dev at lists.llvm.org> writes:> Are you suggesting that static analysis is much inferior than > profiling in finding "next executing function" ? I'm stuck at > deciding which one to prefer & implement during this summer project, > Could you please help me?I suspect this is highly code-dependent. For example, it's probably feasible to use static analysis to determine error paths, at least for fairly well-behaved programs. A whole-program analysis might be able to better determine such paths but that's likely too heavyweight for a JIT. AOT could do it and use metadata to guide the JIT. On some codes, paths within a loop may be fairly evenly distributed over iterations while for others, execution may be highly biased toward a few. This is probably going to be the most difficult thing to analyze statically without a lot of context and even then it may be determined by runtime user input and therefore unknowable statically.> Also if I choose to do PGO stuff with ORC, Can I able to use most of > PGO code available for AOT with the JIT. Is there any downsides to it?I'm sorry I can't really comment on that as I don't have much experience with it. From what little I've looked at the instrumentation code, it seems fairly standard, in that it tries to limit the profiling overhead using minimum spanning tree techniques. Whether that is too heavyweight for a JIT I can't really say. I suspect it would potentially severely impact performance for some codes. Of course, once a path has been determined to be hot you'd probably want to remove the instrumentation. -David
Hi David, Thanks for the reply :) Please see my comments inline. On 30/03/19 3:08 AM, David Greene wrote:> preejackie via llvm-dev <llvm-dev at lists.llvm.org> writes: > >> Are you suggesting that static analysis is much inferior than >> profiling in finding "next executing function" ? I'm stuck at >> deciding which one to prefer & implement during this summer project, >> Could you please help me? > I suspect this is highly code-dependent. For example, it's probably > feasible to use static analysis to determine error paths, at least for > fairly well-behaved programs. A whole-program analysis might be able to > better determine such paths but that's likely too heavyweight for a JIT. > AOT could do it and use metadata to guide the JIT. > > On some codes, paths within a loop may be fairly evenly distributed over > iterations while for others, execution may be highly biased toward a > few. This is probably going to be the most difficult thing to analyze > statically without a lot of context and even then it may be determined > by runtime user input and therefore unknowable statically.Agreed, such kind of analysis requires more time which will directly impacts the execution time of Application in JIT. Even though PGO has extra build/instrument/run cycle I think it will generate good representatives of real time workload. So I decided to implement dynamic profile (instrumentation) for JIT.>> Also if I choose to do PGO stuff with ORC, Can I able to use most of >> PGO code available for AOT with the JIT. Is there any downsides to it? > I'm sorry I can't really comment on that as I don't have much experience > with it. From what little I've looked at the instrumentation code, it > seems fairly standard, in that it tries to limit the profiling overhead > using minimum spanning tree techniques. Whether that is too heavyweight > for a JIT I can't really say. I suspect it would potentially severely > impact performance for some codes. Of course, once a path has been > determined to be hot you'd probably want to remove the instrumentation.Idea here is not only to recompile hot functions but also compiling them ahead of time before they actually start to execute. So I hope that it will not be heavy weight for JIT, given that we ruled out the static analysis approach. It would be nice to reuse many parts of static PGO stuff here, and I will implement to profile, data which is only useful in case of JIT.> -David-- Have a great day! PreeJackie -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190330/fe9ea693/attachment.html>
preejackie <praveenvelliengiri at gmail.com> writes:> > I'm sorry I can't really comment on that as I don't have much > > experience with it. From what little I've looked at the > > instrumentation code, it seems fairly standard, in that it tries to > > limit the profiling overhead using minimum spanning tree techniques. > > Whether that is too heavyweight for a JIT I can't really say. I > > suspect it would potentially severely impact performance for some > > codes. Of course, once a path has been determined to be hot you'd > > probably want to remove the instrumentation. > > Idea here is not only to recompile hot functions but also compiling > them ahead of time before they actually start to execute. So I hope > that it will not be heavy weight for JIT, given that we ruled out the > static analysis approach. It would be nice to reuse many parts of > static PGO stuff here, and I will implement to profile, data which is > only useful in case of JIT.My concern would be with the overhead of the instrumentation in loops. If the common path within the loop body is unknown, instrumentation to determine it might slow down the loop considerably. A sampling approach might be preferred in some cases. I'm really excited for this work though! I think we'll learn a lot about the PGO infrastructure by trying to apply it dynamically. -David