[petsc-dev] ugliness due to missing lapack routines

[Barry Smith]

On Feb 8, 2013, at 12:07 AM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> 
> 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.

  Of course.
> 
> 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 

  Yup.
>  
> 
> > 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.