python speed

[Mike Meyer]

"Harald Armin  Massa" <haraldarminmassa at gmail.com> writes:
>>Faster than assembly? LOL... :)
> why not? Of course, a simple script like "copy 200 bytes from left to
> right" can be handoptimized in assembler and run at optimum speed.
> Maybe there is even a special processor command to do that.

Chances are, version 1 of the system doesn't have the command. Version
2 does, but it's no better than the obvious hand-coded loop. Version 3
finally makes it faster than the hand-coded loop, if you assume you
have the instruction. If you have to test to see if you can use it,
the hand-coded version is equally fast. Version 4 makes it faster even
if you do the test, so you want to use it if you can. Of course, by
then there'll be a *different* command that can do the same thing,j and
is faster in some conditions.

Dealing with this in assembler is a PITA. If you're generating code on
the fly, you generate the correct version for the CPU you're running
on, and that's that. It'll run at least as fast as hand-coded
assembler on every CPU, and faster on some.

If you wire everything down, you can always hand-code assembler that
will be faster than HLL code (though even sharp programmers can miss
tricks the compiler won't). But things don't stay wired down - the CPU
gets upgraded, caches change size, pages change size, the data gets
bigger, etc. Hand-tuned code doesn't deal well with such, whereas
generated code can be made to do just that.

        <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.