How much slower is petsc4py vs c/c++/fortran?I realize it will depend significantly on the code being executed, but what about something simple like a matrix-vector product?
Efficiency of using petsc4py vs. c/c++/fortran
petsc;python
This is a widely-held concern in the scientific programming community, and I would consider the performance uncertainty to be one of the major myths in computational science.  As @fcruz discusses, petsc4py is a wrapper to the PETSc libraries, not a reimplementation of PETSc in Python.  Therefore, you can expect any performance penalties to come from either copying arrays to and from PETSc, or from overhead in your driver code/function calls. petsc4py is very carefully implemented, and as long as you understand the numpy multi-dimensional array interfaces, you can avoid copy overhead. For the majority of use cases I work in, the performance penalty in working in Python is on the order of 10-40%, and I often gain substantially in other ways that more than make up for this performance hit.  In fact, several more experienced HPC Python developers I have talked with hold the opinion that this performance difference can usually be reduced even further, and when Python is driving computationally expensive codes, this will certainly be the case.The petsc4py repository itself features a number of useful examples to illustrate the performance/flexibility tradeoff.  Look in the petsc4py source repository for the demo called perftest, which solves a nonlinear system of equations using both a Python driver and a C driver (over a Fortran kernel provided in App.f90 in that directory).  The performance overhead here is on the order of 10%.As a concrete example, I am part of a team of scientists working on PyClaw, a software package that interfaces into PETSc for parallel grid management and legacy Fortran kernels for solving Riemann problems on cell interfaces.  We performed a fairly careful study of the performance degradation from switching over from a Fortran driver, and you can see the results on the bottom of page 5 in Table 1 in the conference paper.  In our case, we traded a little bit of on-core performance for the capability to easily interface our code to PETSc and Fortran and run efficiently in parallel on tens of thousands of cores.