CPython vs. Jython/JPython

Delaney, Timothy tdelaney at avaya.com
Sun Nov 5 21:34:54 EST 2000


I actually have to disagree with these statements ...

> Benchmarks may show a lot of things, but they can't show that 
> Java can be
> MORE efficient than ANSI C, controlling for other variables. 
[Michael Jordan analogy, 50 pound weight]

This really is not a correct analogy. Source code can be massaged into
better forms. Michael Jordan is already in about the best form a human can
be in ;)

> There is no way that a Java program can be faster than the 
> equivalent C
> program, on the same computer, if the best practices and 
> idioms of each
> language are followed. Of course a skilled programmer using 
> Java (or Visual
> Basic, for that matter) can write more efficient code than a bad C
> programmer, but that's comparing programmers, not languages.

Well, yes and no. When you get to comparing the best programmers of C and
Java, it comes down less to the programmer, and more the the programmer of
the *compiler/virtual machine*.

Quite simply, a higher-level language provides more opportunities for
optimisations. These are often optimisations which are *only* available at
*runtime*. In a statically-compiled language, these optimisations are not
available. Doesn't matter how aggressively a compiler optimises, it can't
see the runtime characteristics of the program. In some (usually quite rare
cases) these runtime optimisations are sufficient for a Java program in a
*very* good VM to beat a C program. Programmer optimisations actually
restrict the capabilities for the compiler/VM to to the same thing in a
better way when the better way is available on a particular platform. Take
for example the following code ...

for i = 1 to 10000
	do something

A simple way of partially unrolling this loop would be

for i = 1 to 1000
	do something
	do something
	do something
	do something
	do something
	do something
	do something
	do something
	do something
	do something

No problems - this should be faster because we don't need to increment the
loop counter, right?

Now consider a hypothetical architecture which can deal with simple loops
*very* efficiently. Perhaps any loop with a simple counter and of no less
than a certain size (say 5 lines of the above pseudocode) can be loaded into
a dedicated part of memory and run over extremely quickly.

Bang. Your optimisation (partial unrolling) just killed the possibility of
using that optimisation that you didn't know about.

Tim Delaney
Avaya Australia
+61 2 9532 9079




More information about the Python-list mailing list