[petsc-dev] ugliness due to missing lapack routines

[Jed Brown]

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>