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>