since developing object oriented software is so cumbersome in C and we are all resistent to doing it in C++
Matthew Knepley
knepley at gmail.com
Sat Dec 5 13:09:33 CST 2009
On Sat, Dec 5, 2009 at 1:06 PM, Jed Brown <jed at 59a2.org> wrote:
> This is an interesting proposal. Two thoughts:
>
> Residual and Jacobian evaluation cannot be written in Python (though it
> can be prototyped there). After a discretization is chosen, the physics
> is usually representable as a tiny kernel (Riemann solvers/pointwise
> operation at quadrature points), but if the user is still in charge of
> the discretization, it will need services from this new PETSc. So we
> need to be able to provide good debugging support across languages and
> concurrency models, i.e. Python/MPI->C/OpenMP->Python->CUDA.
>
> Python is not statically typed. This is both a strength and a weakness,
> but dynamic typing makes debugger support more important because the
> compiler can't catch type errors, instead we'll find them when an
> exception is thrown in the multi-language hybrid environment.
>
This is a great point. Debugging is the Achilles Heel of multi-language
programming. That is
why I propose a dual program. All code should be in a single language, which
allows efficient
debugging. You are correct to point out that Python debugging is all at
runtime.
Then kernels are moved to an accelerator. The nice part here is that
debugging becomes
regression, since we have a working model to test against. The worst
scenario is one in which
a bug only appears in the optimized kernels at a scale unattainable in the
pure Python.
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20091205/abcf93c0/attachment.html>
More information about the petsc-dev
mailing list