since developing object oriented software is so cumbersome in C and we are all resistent to doing it in C++
karpeev at gmail.com
Sat Dec 5 14:20:54 CST 2009
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
Using PyCUDA after Cython as a further accelerator is definitely a
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).
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.
More information about the petsc-dev