[Pyrex] Should Pyrex be in standard Python?

[Bob Ippolito]

On Jan 23, 2004, at 1:52 AM, Paul Prescod wrote:

> Charles Hixson wrote:
>
>> Do you have an example?  I'm thinking of, perhaps, a simple gtk 
>> version of "Hello, World!", with the string stored in a python 
>> string, and the calls to gtk being executed directly from pyrex.
>
> I don't know anything about GTK+. But here's an example of wrapping an 
> XML parser:
>
> http://www.prescod.net/python/pyrexopt/pyxpat/pyxpat.pyx
>
> Maybe you could do the GTK+ version!
>
>> It seems to me that such a thing would be a nice addition to the web 
>> page.
>
> I agree.
>
>> Also, do you have any relative timings for pyrex and C executed over 
>> the exact same code (well, in translation of course but literal 
>> translation).  I know that Python provides increased flexibility, but 
>> how much do you need to pay over the areas where that isn't needed?
>
> It's hard to say. If you don't use Pyrex's features the difference 
> should be small. If you start taking advantage of them then you will 
> get a complete range of performance figures from C to pure Python. It 
> helps to look at the generated C code to recognize when Pyrex features 
> are costing you (e.g. dynamic method calls, exception handling, 
> reference counting).
>
> So the real question is "how low can Pyrex go." My initial test is 
> kind of unbelievable. Pyrex beats C (by a lot). In my second test, 
> Pyrex is 30% slower which is not bad considering that it is not really 
> an optimizing compiler.
>
> Test 1:
>
> Maybe someone out there can help me understand. Am I doing something 
> bone-headed that gives Pyrex a huge advantage??? (OS X 10.2, GCC 3.1)

Use the same compiler flags for Pyrex and regular-C, that could explain 
it.

-bob