Python performance

[Kragen Sitaker]

In article <8a49mu$jsm$1 at nnrp1.deja.com>,  <see_plus_plus at my-deja.com> wrote:
>This is a sensitive response which acknowledges that chess program did
>ruffle the feathers of Python.

Perhaps it's not a Python, then, but a feather boa?  :)

>Indeed, not only on Deep Blue, but several other chess programms running
>on ordinary PC now stand head & shoulder with the elite chess players.
>and they are written in C, no need for a customized Deep Blue.
>
>It proves that when it comes to performance, one does not need assembler
>anymore, but the all beloved, universal & mighty C.

All worship the all-beloved, universal and mighty C!

Note that Doom and all the Quake games have also been written without a
single opcode in assembler.

There are still times when assembler gives you better performance.  But
the article to which you are replying explains why that's not as often
any more.

>Chess is not the only proof, C is so powerful that many other languages
>like Perl/Tcl/Python/Ruby/Rebol/Lua/etc., and even C++ are implemented
>in C.

And even C!  :)

"powerful" is sort of ambiguous.  There's this guy called Turing who
said that, in a certain sense, all decent programming languages are
equally powerful, in that you can program the same algorithms in all of
them.

There are at least four major things that differentiate programming languages:

Microefficiency: How fast do the elementary operations in the programs
run?  This is dependent more on the implementation than on the
language; more later.

Ease of coding: How easy is it to write something hairy and get it right?

Ease of debugging: How easy is it to figure out why your program is broken?

Portability: If you write a program in it, where will the program be
able to run?

Low-level languages like assembler and C (and even, to a lesser extent,
C++) tend to be more efficient, but harder to code and debug.
High-level languages like Scheme and Python tend to be less efficient,
but easier to code and debug.

Sufficient effort by sufficiently-brilliant people can produce
implementations of high-level languages that have good microefficiency;
CMUCL, Rabbit, and the Microsoft JVM come to mind.

But there's another kind of efficiency: efficiency in the large.  This
has to do with how many fundamental operations you have to do to get a
real-world task done; when your programs get hairy, efficiency in the
large becomes more difficult to obtain.  This is not a language matter;
it's a matter of what your program tells the computer to do.

Typically, for really hairy programs, the ease of coding of
higher-level languages results in better efficiency in the large.
There's a good reason why commercial software written in C is still
playing catch-up to things written in Lisp in the 1970s.

Oh, and C is more portable than almost any other language, and
everybody knows it.

>Last but not least, all major software producers including Microsoft are
>producing their products in ... C, maybe also in C++, but not yet in
>Perl/Tcl/Python/etc. AT&T implements most of its critical software in
>C++.

Perhaps more importantly, most free software (Linux, GNU libc, gcc,
Apache, the GIMP, etc.) is written in C.

Microsoft is producing a lot of its stuff in Visual Basic for
Applications, I think.

>When it comes to non-critical, low-performance applications,
>Perl/Tcl/Python/etc. will have their chance to raise their voices.

Software written in high-level languages tends to be more robust, but
less preditable performance-wise, and lower performance in general.

In many cases, the underlying language is relatively unimportant in the
overall efficiency of the system.
-- 
<kragen at pobox.com>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
The Internet stock bubble didn't burst on 1999-11-08.  Hurrah!
<URL:http://www.pobox.com/~kragen/bubble.html>
The power didn't go out on 2000-01-01 either.  :)