When Python outruns C++ ...

[Mike Meyer]

Alexander Schmolck <a.schmolck at gmx.net> writes:
> "Max Khesin" <max at cNOvSisiPonAtecMh.com> writes:
> > > Yes, but humans aren't good optimizing compilers.
> > So who writes optimizing compilers? :).
> Humans. If they were good optimizing compilers themselves why would they
> bother?
> 
> Whether e.g.  assembler code can theoretically achieve better performance than
> fortran code is irrelevant. What matters is whether it is humanly possible to
> hand-code such assembler code.
> 
> For most cases it isn't

I disagree with that statement. Clearly, *someone* knows all the
coding tricks used by the compiler - because they put it into the
compiler. So they can achieve the same level of performance. Unless
you believe that optmiizing compilers produce the best possible
performance - in which case, why are people still doing research on
them? - then humans can probably improve the code in some way, meaning
it will be faster.

The criticial question isn't whether it's possible for a human to
achieve better performance than compiled code. The critical question
is whether the savings from the faster human-produced code is worth
the cost of producing the code. Since producing the code requires
highly specialized, non-portable - and hence expensive - knowledge and
a lot of time per operation, the answer is often "no".

To drag this thread back to the topic, this same argument is the one
seen here for why Python beats C. If your application is "fast enough"
in Python, then any time spent optimizing it in C represents 0
savings, and is a bad investment.

This is why you should write in Python, profile, tune in Python,
profile again, and then resort to C or Fortran. Make sure your
expensive developer time is going to where it makes a difference.

        <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.