since developing object oriented software is so cumbersome in C and we are all resistent to doing it in C++

[Jed Brown]

Somehow this drifted off the list, hopefully the deep citations provide
sufficient context.

On Sat, 5 Dec 2009 13:42:31 -0600, Matthew Knepley <knepley at gmail.com> wrote:
> On Sat, Dec 5, 2009 at 1:32 PM, Jed Brown <jed at 59a2.org> wrote:
> 
> > On Sat, 5 Dec 2009 13:20:20 -0600, Matthew Knepley <knepley at gmail.com>
> > wrote:
> > > I think this involves a change in mindset. Currently, people merge
> > > that tasks of writing correct and optimized code. The movement of a
> > > kernel from Python to C is just an optimization step, and in some
> > > cases (witness Psyco) can be automated. I suggest that the Python is
> > > written in exactly the same style as the CUDA, so its more a matter of
> > > translation then wholesale rewriting.
> >
> > I agree, the "hard" optimization is high-level data flow stuff that can
> > be done in any language, the kernel-level stuff is "easy" in that at
> > least it's local.  But "in the real world", people have some model large
> > model and need to add a new constitutive relation, or another tracer,
> > and it looks like a waste of time to write it twice, so they stuff it
> > into the optimized kernel, make a typo, and have to figure out why it's
> > behaving badly.  Or they do it correctly, but now the next person
> > doesn't want to port all the legacy stuff back to the Python reference
> > before adding a new wave.
> >
> 
> Yes, that comes down to coding discipline. A big reason that PETSc has
> controlled complexity is that coding discipline has been enforced, and
> periodically the code is cleaned up and fixed where we lapsed. I see
> this as a continuum of discipline rather than a new requirement.

It's easy to enforce this *within* PETSc, and I don't have a problem
with maintaining reference implementations of those kernels.  But we
can't require users to follow the same guidelines.  Many/most users are
not going to know in advance how to write Python implementations that
are easily translated to CL/CUDA/whatever.


> > I just think it's a lot to ask, not that it's wrong to ask.
> >
> 
> Its good to be very explicits about the benefits and the costs of
> changing the development model. So far, I think the benefits of this
> approach appear to outweigh the costs. However, the acid test is
> making it easier for some certain researcher to write a certain code,
> so we need a guinea pig.

It might be jumping the gun a little to go looking for a guinea pig
without a prototype (or even a concrete design for one).
Reimplementation is a nontrivial task, even if most of it would be
pretty mechanical.  I think PETSc's object model is really good but it
requires significant boilerplate to implement in C.  In what ways would
a new PETSc, implemented in native Python, be different for the user
than using petsc4py today?  Would it offer a fundamentally different
interface?

Jed

> 
> 
> > And debugging optimized code is sometimes necessary, e.g. the invalid
> > frees due to improper Malloc2 that I fixed the other day only showed up
> > in optimized builds.
> >
> 
> Undeniable. We just need to work to minimize this. It should never become
> routine.
> 
>   Matt
> 
> 
> > Jed
> >
> -- 
> What most experimenters take for granted before they begin their experiments
> is infinitely more interesting than any results to which their experiments
> lead.
> -- Norbert Wiener