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

[Dima Karpeyev]

Cython can accelerate almost any Python code nearly immediately
(although it supports a somewhat restricted subset of Python).
This is simply due to converting it to equivalent C code that is compiled
and runs within CPython.

Then, chunks of the Python code can be explicitly typed, which can result
in a further substantial speedup.  In my experience, however, the code becomes
much less readable (Cython ain't no Python).  Also, the compilation process
becomes somewhat cumbersome: Cython is followed by cc, which slows the
development process.  In addition, debugging can be tricky.  It is
helped a little
bit by the fact that the Cython-generated C includes the original Cython code
as comments.

Using PyCUDA after Cython as a further accelerator is definitely a
promising route:
that's what I'm currently doing to two codes I had to develop from
scratch (and I think Jay
Bardhan will take that route on a brand-new code too).

Dmitry.


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