[petsc-dev] ugliness due to missing lapack routines

[Jed Brown]

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.


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


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

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130207/1e2d2103/attachment.html>