writing python extensions in assembly

[Mensanator]

On May 16, 11:24 am, "inhahe" <inh... at gmail.com> wrote:
> "D'Arcy J.M. Cain" <da... at druid.net> wrote in messagenews: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.

The Society for Inherited Metabolic Disorders?

Why wouldn't the compilers support it? It's part of the x86
architexture,
isn't it?