Realtime image processing in Python
morepypy.blogspot.com
Realtime image processing in Python
1–10 of 19 posts
Re: Realtime image processing in Python
#2To run on OSX:
grab the archive http://wyvern.cs.uni-duesseldorf.de/~antocuni/pypy-image-dem...
brew install pypy
brew install mplayer
pypy demo/magnify.py
pypy demo/sobel.py
Re: Realtime image processing in Python
#3Seriously, the benchmark says it's 590 times faster than regular python. So it's probably 59 times slower than optimized SIMD code?
Re: Realtime image processing in Python
#4Seriously, the benchmark says it's 590 times faster than regular python. So it's probably 59 times slower than optimized SIMD code?
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.
Re: Realtime image processing in Python
#5Seriously, the benchmark says it's 590 times faster than regular python. So it's probably 59 times slower than optimized SIMD code?
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…
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.
Re: Realtime image processing in Python
#6Earlier quoted context omitted.
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…
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 qui…
My point was that 'simd' is far too generic. There are dozens of instruction sets for writing simd code, and numerous compilers targeting them. Lots of compilers generate subpar simd code, so were pypy to do the same that would be far from unusual. If the claim is that pypy generates worse simd code than compiler x + instruction set y, then we're getting somewhere. If the claim was merely "i can write faster asm by hand", then my response is "well, duh".
Re: Realtime image processing in Python
#7Seriously, the benchmark says it's 590 times faster than regular python. So it's probably 59 times slower than optimized SIMD code?
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…
This demo (like all demos) is only showing the best case performance. There are plans to add JIT to C Python ( http://www.python.org/dev/peps/pep-3146/ ), but the numbers listed there don't look very impressive.
Mathematically intense code may run faster when it is compiled JIT, but Python users have relied on specially made libraries (Numpy/Scipy/Gmpy/etc.) to get serious speedup.
Re: Realtime image processing in Python
#8What's the issue with using OpenCV?
Re: Realtime image processing in Python
#9What's the issue with using OpenCV?
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.
Re: Realtime image processing in Python
#10Earlier quoted context omitted.
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…
This demo (like all demos) is only showing the best case performance. There are plans to add JIT to C Python ( http://www.python.org/dev/peps/pep-3146/ ), but the numbers listed there don't look very impressive. Mathematically intense code may run faster when it is compiled JIT, but Python users have relied on specially made libraries (Numpy/Scipy/Gmpy/etc.) to get serious speedup.
Unladen Swallow is dead and won't be merged into CPython.
http://qinsb.blogspot.com/2011/03/unladen-swallow-retrospect...