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

[Matthew Knepley]

On Sat, Dec 5, 2009 at 2:16 PM, Jed Brown <jed at 59a2.org> wrote:

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

We do impose some of our process on users already, such as CHKERRQ and
PetscMalloc. I think the important thing here is to make it as painless as
possible.
The only way I know to do that is use it ourselves all the time, and
ruthlessly
criticize it until it becomes better.

However, right now, I think the only way this approach can actually work is
to force users to
do exactly this.


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

I was being unclear

  1) Not proposing to rewrite PETSc at all. I think we should move to
petsc4py. However
      new things could be added in pure Python.

  2) By guniea pig, I mean initial target. We will not be able to develop
anything without
      an initial application target.

  3) One initial target I propose is PyLith. I already work on it, it has
finite element assembly
      that could be moved to CUDA, and it has a Python front end. Much of
the interaction
      with Petsc can be moved to petsc4py (introducing a dependency but
reducing code
      complexity).

   Matt

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
>



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