writing python extensions in assembly

inhahe inhahe at gmail.com
Fri May 16 12:24:23 EDT 2008


"D'Arcy J.M. Cain" <darcy at druid.net> wrote in message 
news:mailman.1232.1210952591.12834.python-list at python.org...
>
> 2. Once the code is functioning, benchmark it and find the
> bottlenecks.  Replace the problem methods with a C extension.  Refactor
> (and check your unit tests again) if needed to break out the problem
> areas into as small a piece as possible.

There's probably only 2 or 3 basic algorithms that will need to have all 
that speed.

>
> 3.  If it is still slow, embed some assembler where it is slowing down.
>

I won't know if the assembler is faster until I embed it, and if I'm going 
to do that I might as well use it.
Although it's true I'd only have to embed it for one system to see (more or 
less).

>
>> For portability, I'd simply write different asm routines for different
>> systems.  How wide a variety of systems I'd support I don't know.  As a 
>> bare
>> minimum, 32-bit x86, 64-bit x86, and one or more of their available forms 
>> of
>> SIMD.
>
> Even on the same processor you may have different assemblers depending
> on the OS.

yeah I don't know much about that,  I was figuring perhaps I could limit the 
assembler parts / methodology to something I could write generically 
enough.. and if all else fails write for the other OS's or only support 
windows.   also I think I should be using SIMD of some sort, and I'm not 
sure but I highly doubt C++ compilers support SIMD.





More information about the Python-list mailing list