[IPOL discuss] python as an addition to c++

[Ofer]

I just want to add that it is not uncommon for python code to call
subroutines written in c/c++ in cases where speed is an issue.
So software can be written in effective combinations of python and c/c++.
Python code can be inefficient compared to c/c++, but pure c/c++ code can
also be written inefficiently.
As I understand, part of the current review process requires that the c/c++
be well written and adequately efficient.
Perhaps it could be part of the review process of submissions of python
code to require that certain subroutines be written in c/c++ for efficiency.
In general, python code is more compact and easier to understand, which
could potentially make the code easier for review.




On Thu, Jun 6, 2013 at 10:30 AM, Miguel Colom <colom at cmla.ens-cachan.fr>wrote:

> Quoting Nicolas Limare <nicolas.limare at cmla.ens-cachan.fr>:
> >> A parallelized C/C++ as those we have in the current IPOL
> >> publications are complete programs that once compiled run at their
> >> fastest speed using CPU native instructions.
> >> They're only limited by the power of the machine where the run on.
> >
> > I am no very sure of that, Miguel. We could also say that they are
> > very limited by the skills of the developper in low-level
> > optimizations. And sometimes the Python/NumPy internals will be better
> > coded than a researcher's C code, and the python version could be
> > faster. I'll try with a (simplistic) code of mine, to have some
> > numbers for a comparison.
>
> Yes, I think that it's an easy check: to look in the published code
> for operations (patch comparisons, and so on) that in principle are
> not handled by libraries, since they're the algorithm code.
>
> All these code is likely to slow down the execution of the algorithm
> in it's Python version.
>
> However, I'm not saying that we should oppose to the use of Python
> code. We have to study the pros and cons and decide accordingly.
>
> Python is a very good language and many people use it for scientific
> computations. But we have must have in mind that we are likely to face
> an important performance loss if we use it.
>
>
> --
> IPOL - Image Processing On Line   - http://ipol.im/
>
> contact     edit at ipol.im          - http://www.ipol.im/meta/contact/
> news+feeds  twitter @IPOL_journal - http://www.ipol.im/meta/feeds/
> announces   announce at list.ipol.im - http://tools.ipol.im/mm/announce/
> discussions discuss at list.ipol.im  - http://tools.ipol.im/mm/discuss/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tools.ipol.im/mailman/archive/discuss/attachments/20130606/d7a75ae8/attachment.html>