
Realtime image processing in Python - mattyb
http://morepypy.blogspot.com/2011/07/realtime-image-processing-in-python.html
======
mef
To run on OSX:

grab the archive [http://wyvern.cs.uni-duesseldorf.de/~antocuni/pypy-image-
dem...](http://wyvern.cs.uni-duesseldorf.de/~antocuni/pypy-image-demo-
full.tar.bz2)

    
    
      brew install pypy
      brew install mplayer
    
      pypy demo/magnify.py
      pypy demo/sobel.py
    

For me, 24 average fps on magnify.py, 34 average fps on sobel.

------
akivabamberger
What's the issue with using OpenCV?

~~~
alnayyir
Try using it sometime. I work for a startup that is in computer vision and
managing our OpenCV dependent code is the least favorite part of my job.

~~~
Game_Ender
Sure the C interface is clunky and the error messages can be a little hard to
trace their source, but it sure beats having to write all that code from
scratch. Most projects I have seen that make heavy use of OpenCV use a few C++
wrapper classes to make the usage a little smoother.

~~~
zmanian
I concur. It isn't feasible to use the python opencv bindings for nontrivial
tasks.

we use a c++ wrapper around opencv as well.

opencv isn't valuable for its algorithms or its api. The opencv value
proposition is tied up with painstaking optimization of the inner loops of
several high level operations using SIMD intrinsics.

Advances in compiler technology seem to be pointing towards generated code
with similar levels of optimization especially in JIT generated code.

------
herf
Seriously, the benchmark says it's 590 times faster than regular python. So
it's probably 59 times slower than optimized SIMD code?

~~~
kevingadd
Time to feed the troll:

First off, PyPy uses a JIT, so there's no obvious reason why it would _have_
to be slower than 'optimized SIMD code' (whatever that is). The actual
performance all depends on the quality of the JIT and the quality of the input
into the JIT.

Second, they clearly state in the blog post that the PyPy version of the
algorithm is easier to write than the equivalent C++, because the JIT can
transform their polymorphic Python into efficient native code - doing the same
with C++ would require the use of template expansion or a code generator.

Third, if the idea of sacrificing a tiny amount of performance in order to
reduce the cost of development and maintenance is that abhorrent to you,
Python is almost certainly Not For You.

~~~
DarkShikari
_First off, PyPy uses a JIT, so there's no obvious reason why it would have to
be slower than 'optimized SIMD code' (whatever that is)._

If you don't know what SIMD is, you probably shouldn't even talking about
high-performance image processing in the first place. The parent is correct
that this is probably still at least a full order of magnitude slower than
proper SIMD code.

But comparing this to good SIMD is not quite fair, as the intent of this sort
of JIT is to be competitive with naive compiled C, _not_ to be competitive
with optimized assembly routines. Neither is attempting to -- or has a chance
of -- replacing proper hand-written SIMD for performance-critical code.

If you want to automatically generate SIMD code, you'd want something more
along the lines of a special-purpose vector language, like _orc_.

~~~
scott_s
It's completely reasonable to generate SIMD code based on idiomatic uses of
arrays, without requiring the programmer to use a special purpose vector
notation. It's also reasonable to do this in a JIT.

~~~
DarkShikari
It sounds "reasonable", but no compiler in existence seems to be able to do it
efficiently. This suggests to me that it isn't in fact reasonable, as that
sounds like a more reasonable conclusion than "everyone writing compilers is
incompetent".

~~~
serialx
I think differently. Normal C loop codes are hard to optimize using SIMD as
the context and it's freedom can be the limiting factor.

But in python, the vector operations are normally programmed using simple
array semantics. For example in NumPy:

    
    
      >>> a = array( [2,3,4] )
      >>> b = array( [2,3,4] )
      >>> a+b
      [4,6,8]
    

These can be easily converted into SIMD operations.

It's matter of time before PyPy's new NumPy implementation take traction and
make simply beautiful optimizing JITs using that.

