[Pyrex] Pyrex at Pycon

[Paul Prescod]

Greg Ewing wrote:

>>* Performance is as much an attraction for people as bridging (maybe 
>>  more!) but Pyrex is much better at bridging than at performance.
> 
> 
> The way you get performance with Pyrex is *through* bridging.  Pyrex
> isn't meant to speed up pure Python code. There are some things I plan
> to do to improve it in that area -- I think I can get it so it isn't
> ever slower, and might be slightly faster in some cases.
> 
> But compiling pure Python with Pyrex is never going to give
> order-of-magnitude speedups. Doing that would require something like
> type inferencing, and I'm not going there.

I don't think the point is that you would recompile pure Python code as 
Pyrex. Rather you would do Pyrex programs like the one:

cdef int fib(int n):
         return fast_fib(n, 1, 1)

cdef int fast_fib(int n, int a, int b):
         if n==0:
                 return b
         else:
                 return fast_fib(n-1, b, a+b)

That program would totally trounce the equivalent Python program because 
it doesn't do all of the stack frame allocation, tuple construction, 
type conversion etc. But there is no bridging to a C library.

Here's another example that runs twice as fast as Python:

  * http://www.prescod.net/python/pyrexopt/heapq/rxheapq2.pyx

> ...
> People need to keep in mind that Pyrex is still an experiment.  I
> can't tell people where it's going, because I don't know myself yet! 
> I'm still finding out what works and what doesn't.

If you feel that Pyrex is an experiment and others want to use it in 
production code (e.g. Chandler) would you mind if they took your 
experiments and made a production-ready branch that had stable 
interfaces, test cases, optimizations and public repositories of bugs, 
patches and code.

Python started out as a one-person experiment too but people needed to 
use it for real-world projects so it moved to a model where there are 
production branches and experimental branches.

>...
> It depends on what they mean by "autogeneration". It probably won't
> ever be possible to fully automate translation of C declarations to
> Pyrex declarations, but some degree of automation is probably
> possible.

Which declarations do you think would defy automatic translation?

  Paul Prescod