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