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.
