[Coco] Announcing pyDriveWire v0.2

Michael R. Furman n6il at ocs.net
Mon Apr 24 10:27:58 EDT 2017


> On Apr 23, 2017, at 12:07 PM, Allen Huffman <alsplace at pobox.com> wrote:
> 
>> On Apr 22, 2017, at 9:10 PM, Michael Furman <n6il at ocs.net> wrote:
>> 
>> PyDriveWire is a nearly complete DriveWire4 Server written in Python. The goal is to eventually implement all of the features available. The server also implements additional features that are not available in DriveWire4.
> 
> Does pypy perform better than Java? This might be a better solution for running my PiSever on earlier model Pis.

Alan, This is a very good question and it would be interesting to compare them.

Both Python and Java use a Stack-Based Virtual Machine to actually execute your code.  The first difference is that Java wasn’t envisioned as a scripting language so you have to run the compiler to convert your source code to ByteCode.  Python can do both.  You can compile the Python code into ByteCode (.pyc) or leave it as script and Python will automatically compile it at run-time.  Python also has an interactive REPL mode (Read, Execute, Print, Loop) where each line you type is compiled and run on demand.

Python has a few different Virtual Machine implementations.  The normal one is named “CPython” and the one that is recommended for pyDriveWire is a different implantation called “PyPy”.  These two implementations are designed differently but they both implement the Python Language.  CPython is not really optimized for performance.  I know you have studied the Coco’s BASIC interpreter to you will understand this.  The first time you run a script the Python code is compiled to ByteCode and saved in the Virtual Machine’s Memory (Think about loading an ASCII  Basic program from disk and the BASIC interpreter Tokenizing it) Then when you type RUN the interpreter simply reads all the tokens one at a time in the specified sequence and runs them.  The CPyhon VirtualMachine does the same thing every time your run your program.  PyPy is optimized for performance and it actually uses similar technology to Java.  Java and PyPy have what is called “Just In Time Compilation” (JIT)   When you first run a Java Program or a Python Program in PyPy the VirtualMachines just interpret the ByteCodes in sequence as the compiler gave it to them.  A JIT VirtualMachine will keep some statistics of how often a certain piece of code is run.  Blocks of code that are run many times will automatically get a second compilation stage that is done behind the scenes without you knowing about it.  This second compilation stage compiles the ByteCode into Machine Code.  This is similar to Multi-Pass C compilers, that the first stage is from C to intermediate code, and the second stage is from Intermediate Code to Machine Code.  So in both Java and Pypy if you have a loop that runs continuously it will get this second compilation stage and that loop will run much faster than when the ByteCodes were interpreted. 

I know I’ve entered TL;DR territory here but IMHO the answer to your question is that the Java VM has had many many years of optimizations in it’s JIT ByteCode Compiler.  I don’t know the history of PyPy but I don’t think it is as widely used as Java has been over the years, so it’s likely that it’s probably not as fast as Java. OTOH, since PyPy is newer and doesn’t have such a large user base and it can take advantage of newer advances in compiler technology that could be hard for Java to implement.

There is a pretty simple test case where you can observe this happening with pyDriveWire.  If you set up VCC with the Becker Port and crank up VCC to maximum speed and connect it to freshly-started pyDriveWire and do something like boot up NitrOS-9 you can actually see the loading dots start out at one speed and then you can observe that speed increasing as the JIT compilation kicks in.  You don’t see this on Java DriveWire4, so either the ByteCode interpreter in Java is faster or the JIT compiler is tuned to kick in sooner.

—

Michael R. Furman
Email: n6il at ocs.net
Phone: +1 (408) 480-5865


More information about the Coco mailing list