python speed
Donn Cave
donn at u.washington.edu
Wed Nov 30 17:19:41 EST 2005
In article <86sltdn6ma.fsf at bhuda.mired.org>, Mike Meyer <mwm at mired.org>
wrote:
> "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.
Actually I think the post you quote went on to make a similar
point.
I read yesterday morning in the paper that the Goto Basic Linear
Algebra Subroutines, by a Mr. Kazushige Goto, are still the most
efficient library of functions for their purpose for use in
supercomputing applications. Apparently hand-optimized assembler
for specific processors.
http://seattlepi.nwsource.com/business/250070_goto29.html
(actually from the NY Times, apparently)
Donn Cave, donn at u.washington.edu
More information about the Python-list
mailing list