Bytecode machines (and pyrex and psyco)

Jonathan Gardner <[email protected]>
Newsgroups gmane.comp.lang.prothon.user
Message-ID <[email protected]>
It was my understanding that Parrot (the new register-based bytecode 
machine) gives very, very successful results that challenge even the speed 
of C. Despite their academic unsavviness, register based machines are well 
understood and fast.

You are talking about taking Prothon and whatever machine it is working on 
and executing code at a lower level for speed (via Psyco and Pyrex type 
enhancments). I think we should examine the core reason for Python's 
original slowness.

I understand that Python currently uses a stack-based machine. These have 
been shown to be slow, but easy to implement. While academics enjoy the 
simplicity and theoretical completeness of stack-based machines, actual 
implementations are slow. The only way to make a stack-based machine faster 
is to move off of the stack and into a lower level.

If you were to take either Parrot or some other register-based machine and 
use that as the machine for Prothon, then you would probably get most of 
the speed you want. Optimizations would be added at two levels. First, you 
can compile prothon code to more efficient bytecode for the machine. 
Second, you can write a more intelligent machine that uses optimizations.

I have seen the actual implementation of Parrot, and what I saw didn't 
excite me very much. They are working from a perl point of view (everything 
a scalar, list, or hash), rather than a more pythonic point of view 
(everything an object). Maybe having more specialized registers based on 
types (int, long, string, float, "anything") would make it that much more 
easy to optimize. (add two ints? That's easy. add two "anything"s? That's 
more difficult.)

I have never written a register-based machine myself. I have never written a 
machine, period. However, examining the problems from the outside, this is 
what I see.

(1) Decide what registers to have and what kind of registers to use. Will 
you allow the number of registers to vary from implementation to 
implementation? Will you allow the number of registers to change during 
execution?

(2) Decide what instruction set to use. You'll have of course the "move 
into/out of memory from/to a register" instructions. You'll have 
instructions for basic, common operations, "add", "subtract", etc...

Once you get a working implementation, then you can start thinking about 
optimization, on both the compiling and the execution ends.

-- 
Jonathan Gardner
[email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.