compiling python 1.4 for SGI/MIPS R10000 
Author Message
 compiling python 1.4 for SGI/MIPS R10000

Recently as an exercise in using the profiling tools and compiler
available on the latest Silicon Graphics server system, I compiled
the python 1.4 system.  The test bucket included software contributed
by people who post to this list (special thanks to Andrew Kuchling
and Aaron Watters).  

A report on the experience can be read at this URL:
http://www.*-*-*.com/

Comments welcome, and thanks again.




Fri, 04 Jun 1999 03:00:00 GMT  
 compiling python 1.4 for SGI/MIPS R10000


: Recently as an exercise in using the profiling tools and compiler
: available on the latest Silicon Graphics server system, I compiled
: [and profiled] the Python 1.4 system. ...
:
: A report on the experience can be read at this URL:
: http://reality.sgi.com/employees/cortesi/war.pyth.html

David goes on to report that the bulk of the interpreter's time is spent
inside the giant switch statement that's at the heart eval_code2().  He
goes on to conclude that optimization of this code is unlikely.

I'm not so sure.  As an exercise, I completely rewrote the heart of the
Python 1.3 interpreter a year ago.  My goal was to improve its performance
and drastically simplify the "inner loop".  I made many changes, and it's
hard to describe them here without confusing folks who aren't intimately
familiar the innards of the interpreter.  But allow me a few words.

I chiseled away at that big switch statement, ultimately reducing the
interpreter's inner loop to something like this:
    do {
            fetch opcode;
            opcodeTable = table of function pointers corresponding to
                          the type of the "left" argument of an expression;
            dispatchFunctionPtr = opcodeTable [opcode] . dispatchFunction;
            why = (*dispatchFunctionPtr) (framePtr, oparg);
    } while (why == WHY_NOT);

Thus Python bytecodes are used as indices into an array of function
pointers, where each function implements a primitive opcode.  There are
several such arrays -- each Python type has an opcode array.  This
eliminates the need to inspect object types within each arm of the switch
statement.  Instead, we provide a set of functions to implement integer
opcodes, a set to implement string opcodes, a set to implement floating
point opcodes, etc.  This will undoubtedly sound familiar to anyone who
has contemplated the inner workings of C++ or Smalltalk.

The changes were pervasive - I had to make all "static" objects (such as
None and most primitive types) into full-fledged objects.  I believe this
to be a Good Thing in any case.  I also reworked stack frames to make them
more versatile and MT-safe.

In the end, I had an interpreter that could look at an opcode and the
argument(s) on the stack and directly dispatch to the appropriate function
to implement the operation given the types.

Alas, performance was not much improved, due to the added overhead imposed
by the extra level of function calls.  I did my development on a
Macintosh, and it turns out that the Metrowerks C compiler emits pretty
horrid code for indirect function calls.   (And the optimization options
it offers are just for show; they don't actually do anything useful.)
After spending too many nights trying to think up ways to coerce the
Metrowerks compiler into using registers in ways that seemed obvious to
me, I decided to call it quits.

--



Mon, 05 Jul 1999 03:00:00 GMT  
 compiling python 1.4 for SGI/MIPS R10000

Quote:

>I chiseled away at that big switch statement, reducing the
>interpreter's inner loop to something like this:
>    do {
>            fetch opcode;
>            opcodeTable = table of function pointers corresponding
>                          to the type of the "left" argument of an
>                          expression;
>            dispatchFunctionPtr = opcodeTable [opcode].dispatchFunction;
>            why = (*dispatchFunctionPtr) (framePtr, oparg);
>    } while (why == WHY_NOT);>
>Thus Python bytecodes are used as indices into an array of function
>pointers...

The Forth programmers here will recognize that you have promoted the
inner interpreter from TOKEN THREADED to ADDRESS THREADED, as it were.
No doubt that's where you got the idea, aye?

I congratulate you.

paul






Tue, 06 Jul 1999 03:00:00 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. Strange problem while installing python 1.4 on SGI Irix 5.3

2. ILU support Python 1.4 b2 on SGI

3. Error compiling tcl8.3.3 on SGI IRIX6.5 IP27 mips

4. compiling Python 1.4 on Linux/Alpha

5. Help sought for compiling Python 1.4 on Solaris 2.4 with gcc 2.7.2

6. Compiling python 1.4 b3 with oracle module

7. Lisp environment for SGI Irix 6.2 R10000

8. 8.0b2 problems on SGI R10000 w Irix64 6.4

9. Strange problem while installing 1.4 on SGI Irix 5.3

10. Q: tbcload 1.4 for HP-UX and SGI ELF 64 bit

11. Python, MySQL, and MySQLmodule.c 1.4 - Python Version.

12. Version problem -- Python 1.4 V Python 1.5.1

 

 
Powered by phpBB® Forum Software