[petsc-dev] ugliness due to missing lapack routines

[Barry Smith]

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

> 
> On Thu, Feb 7, 2013 at 10:35 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> > How would we have plugins and dynamic configuration without a JIT? You want to recompile (using the god preprocessor that sees all and knows all) every time the user tweaks the model or algorithm? No thank you.
> 
>   Oh come on. It takes 1 minute to compile all of PETSc on my laptop. With the proper dependencies known, a change that affects only a few places (like most editing changes) would take seconds to update the dynamic library.
> 
> I read comments like this and really don't understand what you are advocating.
> 
> Why don't we get rid of the options database and just configure the right method using the build system/preprocessor/whatever?

   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. 

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

   Yes I am advocating a radical overthrow of the current state of affairs in software, but in an evolutionary way :-)

   Barry