On Thu, Feb 7, 2013 at 11:57 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> At build time the user may say I know this, this and this. Those get > compiled in. They then use the built thing for a while and are free to set > at runtime any of the other many options that were not compiled in. > How would they specify what they want to use? Hopefully using the options database. Inlining could then be thought of as an extreme case of profile-guided optimization, in the sense that you run an instrumented instance of the code to determine which decisions have been made, then recompile (mostly just fusing the right things) and > > > Or are you just JITing and caching the result of the JIT pass in a > "library" that you'll keep around for a while (maybe several separate runs) > before it gets gc'd? > > So yes it is JIT like, if you will. The point is that conceptually "JIT" > is/can be a spectrum of possibilities and should be treated that way. > Developers shouldn't need a different process or mindset because it is > "JIT" or not. > You're going to have to annotate/teach/declare what should be jitted. My JIT-based suggestion is mostly about using a special mechanism for assigning and calling those chaseable pointers, so that they could be resolved later using the JIT. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130208/b6950b43/attachment.html>
