Python Speed Question and Opinion

[David M. Cooke]

At some point, beliavsky at aol.com wrote:

> Peter Hickman <peter at semantico.com> wrote in message news:<40c58636$0$8219$afc38c87 at news.easynet.co.uk>...
>
> <snip>
>
>> 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.

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.

-- 
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke
|cookedm(at)physics(dot)mcmaster(dot)ca