Python Speed Question and Opinion

[Jacek Generowicz]

No one that has ever said to me that all they are concerned about is
speed has actually gone for assembler, they tend to start eulogizing
'rapid development', 'ease of debugging' and other claptrap.

You're forgetting other claptrap, such as "correctenss of
program". All irrelevant twaddle, I completely agree.

I see that Peter Hansen has neatly re-iterated my original point
(which you appear to have missed), so I won't address that.


[Warning to the reader: The above message was brought to you with a
higher level of irony than you may be used to.]

 

[Paramjit Oberoi]

Jacek already made this point, but I'll make it again. Assembler

is sometimes *not* the way to write the fastest code. (Though
sometimes it is.) Optimizing compilers for some languages such as
C can actually produce *faster* code by choosing combinations of
opcodes and side-effects that even an assembly programmer would be
nuts to use in most cases, largely because it would make the code
even more obscure than it already is but also because they might not
even think of it.

Very true, and I would replace the "sometimes not the way to write the
fastest code" with "almost never...". Especially when optimizing code for
a modern processor, a compiler will be much better at reordering
instructions so that they pass through the execution pipeline more
smoothly.

If you are writing a critical 20-instruction inner loop and are willing to
spend hours, if not days, experimenting with different instruction
sequences, you may be able to get slightly better performance than the
code generated by the compiler; but in most other cases it's best to leave
it to the compiler.

-param

 

[beliavsky]

You are correct, it is just that if all you are concerned about is speed then
assembler is what you need. However when you put this to people you find out
that what they really want is 'easy to write fast programs'. Assembler comes
with many hurdles but you are not going to get any faster using a higher level
language.

Do you have experience to back up your claims?

I have not written assembler, but sources I respect tell me that good
C++ and Fortran (especially Fortran 95 with its array operations)
compilers DO let you write programs in a high-level language that are
more efficient than the hand-coded assembly you might produce (taking
infinitely longer to write).

Given an infinite amount of programming time, very few programmers are
going to write assembly code that outperforms LAPACK (in Fortran) for
linear algrebra or FFTW (in C) for Fourier transforms.

Your point that Python is a productive language despite its slower
execution speed is valid, but don't pretend that the natural
alternative is assembly language.

 

[David M. Cooke]

Do you have experience to back up your claims?

I have not written assembler, but sources I respect tell me that good
C++ and Fortran (especially Fortran 95 with its array operations)
compilers DO let you write programs in a high-level language that are
more efficient than the hand-coded assembly you might produce (taking
infinitely longer to write).

Given an infinite amount of programming time, very few programmers are
going to write assembly code that outperforms LAPACK (in Fortran) for
linear algrebra or FFTW (in C) for Fourier transforms.

Those are interesting examples: FFTW actually uses routines coded in
assembly language, and ATLAS (a common implmentation of BLAS, which
underlies LAPACK), also uses assembly language.

The difference is the code is generated by a program: basically, the
authors have made custom compilers to determine the best combination
for the architecture. In the case of ATLAS, benchmarks can be run to
determine which combinations of parameters are the best for a
particular machine (taking into account cache size, for instance).

Some routines *are* hand-written assembly, but they're small enough,
and used enough that someone sat down and thought about it long and
hard.

 

[A. Lloyd Flanagan]

Maboroshi wrote:




I have taken the liberty of taking a few of the comments made
in this thread and writing them down here:
http://www.razorvine.net/python/PythonSpeed
I've added a few other things related to Python's performance,
such as a short reference to Psyco.


--Irmen de Jong.

Nice page. May I suggest you link into the "official" python wiki at
http://www.python.org/cgi-bin/moinmoin/? I'd like to see a lot more
contribution to that one.

 

[Jacek Generowicz]

Those are interesting examples: FFTW actually uses routines coded in
assembly language,

Just to expand on FFTW, as it is a very good example (which I was
tempeted to mention in my initial message). FFTW is based around
"codelets" written in C. But the codelets themselves were not written
by a human, they were written by an OCaml program, which itself was
written by a human. The really fascinating point about this is that
the codelet generator came up with a few very domain-specific
algorithms which were actually more efficent than any known to man
until that time, in spite of it having been a set of algorithms which
had been studied for decades.

http://fftw.org/pldi99.pdf

So, the moral of the story is, once again, that generating low-level
code by hand is likely not to be the way to get the fastest performing
code in the end; getting a higher level language to do it for you is
likely to be a better way to go.

 

[Peter Hickman]

Do you have experience to back up your claims?

Yes, I used to write assembler (and C and Fortran).

I have not written assembler, but sources I respect tell me that good
C++ and Fortran (especially Fortran 95 with its array operations)
compilers DO let you write programs in a high-level language that are
more efficient than the hand-coded assembly you might produce (taking
infinitely longer to write).

At a basic level any C, C++ or Fortran compiler must produce machine code, and
that is what an assembler will produce. So if it can be compiled from C to
machine code it can also be written in assembler. Take you C compiler and add
the -S switch, see that *.s file that it kicked out, that is the assembler for
your C. So as your C is now just assembler, if a machine can write it then so
can a human.

Given an infinite amount of programming time, very few programmers are
going to write assembly code that outperforms LAPACK (in Fortran) for
linear algrebra or FFTW (in C) for Fourier transforms.

No one has ever claimed that assembler was easy or quick to develop, and good
assembler programmers are very hard to find. For that matter competent assembler
programmers are hard to find. They also have off days which compilers don't have
so the quality of their work is not consistent, but then again compilers lack
problem specific knowledge that would allow an assembler programmer to shave a
few op codes out of a routine.

It all comes down to just how important is speed of execution, most people will
say that it is number one until they find out just what it takes. There is also
the economic issue that faster hardware is probably cheaper than the development
costs.

Your point that Python is a productive language despite its slower
execution speed is valid, but don't pretend that the natural
alternative is assembly language.

I have never pretended that python was a natural alternative to assembler only
that what people want 'ease of development' and what they say they want 'speed
of execution' means that they should be looking at languages like python which
provide many good things with respectable performance and the option to drop
down to C for the critical parts and tools like psyco to help things along.

If speed of execution is really an issue but they can't stomach assembler then
you want C, C++ or Fortran, if you can't stomach that then give up on the 'speed
of execution'.

Anyone who is writing python and has speed of execution as a priority has a
screw loose, just as anyone writing assembler and expecting ease of development.

 

[Aaron Brady]

Anyone who is writing python and has speed of execution as a priority has a
screw loose, just as anyone writing assembler and expecting ease of
development.

http://www.dadgum.com/james/performance.html

The above essay, while dealing with Erlang, does something to dispell the
myth that performace == assembler.

A sequential-scan in assembler is still a sequential-scan - if you can
implement, for example, BTrees easily in Python, then on large datasets
that's a win.

Aaron

http://insom.me.uk/blog/

 

[Irmen de Jong]

I have taken the liberty of taking a few of the comments made
in this thread and writing them down here:
http://www.razorvine.net/python/PythonSpeed

Thomas Waldmann convinced me to move the page to the
'official' Python Wiki at python.org. so for the record,
the current URL of that page is:
http://www.python.org/cgi-bin/moinmoin/PythonSpeed

--Irmen