Python Speed Question and Opinion

[Peter Hickman]

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 
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.