Hacker News Reader

Comment by DarkShikari | Hacker News Reader

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.

View on HN

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".

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.

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".

I think it's more that the application of it is niche enough that it's not worth the engineering effort for most general purpose compilers - the people who need it are often experts anyway, and are willing to do the optimization by hand.

I see this as being similar to why we're only now taking abstractions and compilers geared towards parallelism seriously for mainstream programming: not enough people needed it to justify the effort required.

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.

Sounds about right. In GPU drivers, we keep specialized shaders as hand-tuned GPU assembly, not as GLSL/HLSL. This is just a very cool example of Python running at C speed, not Python running at --omg-optimized x264 assembly routine speed. :3

Reply on news.ycombinator.com