[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: Re: [pygame] Python and Speed



On Thu, Apr 17, 2008 at 2:21 PM, Greg Ewing <greg.ewing@xxxxxxxxxxxxxxxx>
wrote:
> René Dudfield wrote:
>
>
> > 2. - asm optimizations.  There seems to be
> >
> > almost no asm optimizations in CPython.
> >
>
>  That's a deliberate policy. One of the goals of CPython
>  is to be very portable and written in a very straightforward
>  way. Including special pieces of asm for particular
>  architectures isn't usually considered worth the
>  maintenance effort required.
>

Other, more portable, software has proved this to be somewhat wrong I

think.  Optional asm software is used in a lot of software today to
good effect.  Also this decision was made a while ago, and things have
changed since then I think.

- python now has unittests.  So testing that the asm code works, and
keeps working correctly is much easier.
- x86 is now very common.  Most mainstream server, and desktops use
x86.  So just targeting x86 gives you a lot more benefit now.
- SIMD instructions are the fast ones... so you don't actually have to
learn all that much to write fast asm - you only have to learn a
subset of asm.  You can get compilers to generate the first pass of
the function, and then modify it.  Of course writing the fastest
possible asm still requires effort - but it is fairly easy for a
novice to beat a compiler with SIMD code.
- advanced compilers can generate asm, which can then be used by worse
compilers.  eg, the intel compiler, or vectorc compiler can be used to
generate asm, and then be included into C code compiled by gcc.
- libraries of fast, tested asm code are available.  eg, from amd,
intel and others.
- python, and FOSS now has a much larger development community with
more asm experts.

I see a slight problem with these architecture specific optimisations, once you
release your game out onto the general public, even if you were using super
optimized awesomeness and everything ran fine, the majority of people will
be running whatever version of the library came with there OS rather compiling
there own and it might be somewhat lacking.