Python Speed Question and Opinion
peter at semantico.com
Wed Jun 9 10:49:34 CEST 2004
beliavsky at aol.com wrote:
> 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
> 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
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.
More information about the Python-list