On Sat, Dec 5, 2009 at 2:16 PM, Jed Brown <span dir="ltr"><<a href="mailto:jed@59a2.org">jed@59a2.org</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Somehow this drifted off the list, hopefully the deep citations provide<br>
sufficient context.<br>
<div class="im"><br>
On Sat, 5 Dec 2009 13:42:31 -0600, Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> wrote:<br>
> On Sat, Dec 5, 2009 at 1:32 PM, Jed Brown <<a href="mailto:jed@59a2.org">jed@59a2.org</a>> wrote:<br>
><br>
> > On Sat, 5 Dec 2009 13:20:20 -0600, Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>><br>
> > wrote:<br>
> > > I think this involves a change in mindset. Currently, people merge<br>
> > > that tasks of writing correct and optimized code. The movement of a<br>
> > > kernel from Python to C is just an optimization step, and in some<br>
> > > cases (witness Psyco) can be automated. I suggest that the Python is<br>
> > > written in exactly the same style as the CUDA, so its more a matter of<br>
> > > translation then wholesale rewriting.<br>
> ><br>
> > I agree, the "hard" optimization is high-level data flow stuff that can<br>
> > be done in any language, the kernel-level stuff is "easy" in that at<br>
> > least it's local. But "in the real world", people have some model large<br>
> > model and need to add a new constitutive relation, or another tracer,<br>
> > and it looks like a waste of time to write it twice, so they stuff it<br>
> > into the optimized kernel, make a typo, and have to figure out why it's<br>
> > behaving badly. Or they do it correctly, but now the next person<br>
> > doesn't want to port all the legacy stuff back to the Python reference<br>
> > before adding a new wave.<br>
> ><br>
><br>
> Yes, that comes down to coding discipline. A big reason that PETSc has<br>
> controlled complexity is that coding discipline has been enforced, and<br>
> periodically the code is cleaned up and fixed where we lapsed. I see<br>
> this as a continuum of discipline rather than a new requirement.<br>
<br>
</div>It's easy to enforce this *within* PETSc, and I don't have a problem<br>
with maintaining reference implementations of those kernels. But we<br>
can't require users to follow the same guidelines. Many/most users are<br>
not going to know in advance how to write Python implementations that<br>
are easily translated to CL/CUDA/whatever.<br><div class="im"></div></blockquote><div><br>We do impose some of our process on users already, such as CHKERRQ and<br>PetscMalloc. I think the important thing here is to make it as painless as possible.<br>
The only way I know to do that is use it ourselves all the time, and ruthlessly<br>criticize it until it becomes better.<br><br>However, right now, I think the only way this approach can actually work is to force users to<br>
do exactly this.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">
> > I just think it's a lot to ask, not that it's wrong to ask.<br>
> ><br>
><br>
> Its good to be very explicits about the benefits and the costs of<br>
> changing the development model. So far, I think the benefits of this<br>
> approach appear to outweigh the costs. However, the acid test is<br>
> making it easier for some certain researcher to write a certain code,<br>
> so we need a guinea pig.<br>
<br>
</div>It might be jumping the gun a little to go looking for a guinea pig<br>
without a prototype (or even a concrete design for one).<br>
Reimplementation is a nontrivial task, even if most of it would be<br>
pretty mechanical. I think PETSc's object model is really good but it<br>
requires significant boilerplate to implement in C. In what ways would<br>
a new PETSc, implemented in native Python, be different for the user<br>
than using petsc4py today? Would it offer a fundamentally different<br>
interface?<font color="#888888"><br></font></blockquote><div><br>I was being unclear<br><br> 1) Not proposing to rewrite PETSc at all. I think we should move to petsc4py. However<br> new things could be added in pure Python.<br>
<br> 2) By guniea pig, I mean initial target. We will not be able to develop anything without<br> an initial application target.<br><br> 3) One initial target I propose is PyLith. I already work on it, it has finite element assembly<br>
that could be moved to CUDA, and it has a Python front end. Much of the interaction<br> with Petsc can be moved to petsc4py (introducing a dependency but reducing code<br> complexity).<br><br> Matt<br><br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><font color="#888888">
Jed<br>
</font><div><div></div><div class="h5"><br>
><br>
><br>
> > And debugging optimized code is sometimes necessary, e.g. the invalid<br>
> > frees due to improper Malloc2 that I fixed the other day only showed up<br>
> > in optimized builds.<br>
> ><br>
><br>
> Undeniable. We just need to work to minimize this. It should never become<br>
> routine.<br>
><br>
> Matt<br>
><br>
><br>
> > Jed<br>
> ><br>
> --<br>
> What most experimenters take for granted before they begin their experiments<br>
> is infinitely more interesting than any results to which their experiments<br>
> lead.<br>
> -- Norbert Wiener<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
-- Norbert Wiener<br>