how fast is Python code - another detail

[beliavsky at aol.com]

"Terry Reedy" <tjreedy at udel.edu> wrote in message news:<mailman.5.1078451040.19534.python-list at python.org>...
> "Gregor Lingl" <glingl at aon.at> wrote in message
> news:404778E4.9090601 at aon.at...
> >So my question: why does the
> > Python interpreter not recognize this identity and internally
> > replace the latter by the first in order to get *much*
> > better performance?
> 
> The interpreter does not do optimization.  'Optimizing' complilers are
> often buggy, which is to say, grossy dis-optimized -- as has been too often
> discovered, from reports here and on PyDev, when compiling the interpreter
> with 'optimzing' C compilers.

My experience with Fortran compilers is that the ones that can
aggressively optimize are not more buggy than the other ones, perhaps
in part because the fast compilers attract more users, who report more
bugs that are ironed out. In particular, Compaq Visual Fortran is a
highly optimizing, non-buggy compiler that handily beats Python in
speed comparisons of numerical code. C is more difficult to optimize
than Fortran because of its use of pointers. Optimizing compilers
always have a switch that let you compile with no optimization. When
using optimization, the user should check that results are the same as
with no optimization.

<SNIP>
> Speed is secondary to correctness, appropriately defined.

In production use, both are often vitally important. If you are
modelling a lot of data, a slow compiler or programming language may
force you to use an oversimplified model.