Python's Performance

[Paul Boddie]

Dennis Lee Bieber wrote:
> I'd consider that BASIC to be a fully interpreted language, as the
> tokens are still a one-for-one equivalence of the source code. Python,
> UCSD, and Java are not one-for-one, so on that basis, they fit the
> definition of a compiled language...

That's an interesting definition which at least attempts to consider
the issue from a perspective other than that which is concerned with
whether hardware is in use, what kind of hardware, and so on.

> The difficulty is that the target architecture in not realized in hardware.

Or isn't perhaps feasible/viable for hardware realisation: one of the
EuroPython speakers dangled the promise of hardware support for
high-level languages (the classic "Python on a chip" concept), but
there are probably plenty of areas where hardware support can assist
software virtual machines without going to all the trouble of
implementing such virtual machines in hardware completely.

> And then... I believe the PowerPC chipset emulated the 680xx instruction set, didn't it?

There may have been some architectural overlap between PowerPC and
M68K, but the PowerMacintosh computers used dynamic
recompilation/translation software to execute legacy applications.

In the case of CPython, the principal technological factor in
determining how "interpreted" it is seems to be the complexity of the
bytecode instructions, and I believe some work was done to investigate
other instructions that might improve performance [2]. Were the most
complex instructions replaced with simpler ones, a more performant
implementation might be possible, although the work required to
translate programs to such a simplified instruction set is very
difficult indeed.

On the subject of other virtual machine implementations, I wonder what
happened to this one:

http://effbot.org/zone/pytte.htm

Fredrik? ;-)

Paul

[1] Theo F. de Ridder, "Enabling bare Python as universal connector for
ad-hoc networks":
http://www.python-in-business.org/ep2005/download.cpy?document=8912
(warning: huge presentation!)
[2] Brett Cannon, "Localized Type Inference of Atomic Types in Python":
http://www.ocf.berkeley.edu/~bac/thesis.pdf