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]