[petsc-dev] ugliness due to missing lapack routines

[Barry Smith]

On Feb 7, 2013, at 11:46 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> 
> On Thu, Feb 7, 2013 at 11:29 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
>    Because I didn't have a decent build system/preprocessor/whatever back then :-)
> 
>    You are right there is a lot of potential overlap with configuring more at compile time versus using runtime options. PETSc has always focused on runtime flexibility (and it has served us well) but with things like mixing precisions and small problems I think we need to clean up our act on configuration time flexibility and stop using regexp and CPP as our configuration time tools.
> 
>    My firm believe is that eventually the syntax and mechanism for runtime polymorphism and compile time polymorphism will merge and from the code developers point of view be completely flexible.
> 
> Yes, the syntactic difference between early and late binding is jarring in most languages.
  
   And moronically so. Good we finally agree on something.
>  
> 
>   So yes eventually I want users to be able to use the same mechanism to say at compile time I want -snes_rtol to be .035  or -dm_grid_x 83  or -ksp_type lgrmes or to instead decide to say it at run time (no, no JIT, they would be using a different library in the two cases).
> 
> You're going to compile a different library for every combination so that it doesn't need to build it at run-time?

   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. 

> 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.
>  
> 
>    Yes I am advocating a radical overthrow of the current state of affairs in software, but in an evolutionary way :-)
> 
> Good luck. I think your proposal is insufficiently specified and has fatal flaws that will prevent it from functioning in anything resembling the form we're currently discussing.

   See my other recent mail.
> 
> I'm more interested in addressing specific classes of desired fusion at a local level and in a way that doesn't spoil the user interface. I don't want to write logic in the code manipulator.