Python's Performance

[Mike Meyer]

Donn Cave <donn at u.washington.edu> writes:
> In article <861x2t2m7s.fsf at bhuda.mired.org>, Mike Meyer <mwm at mired.org> 
> wrote:
>
>> Donn Cave <donn at u.washington.edu> writes:
>> > I agree that there are many shades of grey here, but there's also a
>> > real black that's sharply distinct and easy to find -- real native
>> > code binaries are not interpreted.
>> 
>> Except when they are. Many machines are microcoded, which means your
>> "real native code binary" is interpreted by a microcode program stored
>> in the control store. Most machines don't have a writeable control
>> store (WCS), so you generally can't change the interpreter, but that's
>> not always true. In the simple case, a WCS lets the vendor fix
>> "hardware" bugs by providing a new version of the microcode. In the
>> extreme cases, you get OS's in which the control store is part of the
>> process state, so different processes can have radically different
>> formats for their "native code binaries".
>> 
>> Then there's the Nanodata QM-1, whose microcode was interpreted by
>> "nanocode".
>
> Fine -- given a Python Chip computer, Python programs are
> native code.  It can use microcode, if that helps.

Historical evidence is that general purpose CPUs will (eventually)
outperform custom Python chip.

> The VAX/11 microcode was just a software extension of the
> CPU hardware, implementing some extra instructions, the way
> I remember it.  I don't recall that it was of any more than
> academic interest to anyone using the computer - though it
> may have been software in a sense, it was on the hardware
> side of the wall.

It was of more than academic interest to people interested in
performance. As you moved up and down the VAX line, instructions
migrated into/out of microcode, and the relative performance of the
instructions changed. In particular, the magic "evaluate a polynomial"
instruction - which made doing multi-dimensional array indexing
trivial - was slower or faster than the obvious sequence of simple
instructions for doing the same depending on whether or not that
instruction was interpreted.

>From (roughly) the same era, the 370 line was all microcoded. The
machines in the line had *radically* different underlying
architectures. Estimates were that if you could write to the native
hardware, you'd pick up about 10% in performance - but your code
wouldn't port to any other machine 370 in the 370 line.

Just to be strange, some of the 370s had control stores in main
memory. Meaning a stray pointer could trash your instruction set.

> On the software side of the wall, if your program can go over the
> wall by itself, then it's native.

And what does "by itself" mean? If it requires that you load the WCS,
does that mean it's interpreted? What if what it wants in the WCS is
required to run the OS? What if what it wants in the WCS isn't
required to run the OS, but is always loaded on the system the author
runs on, or is available as an extension module from the vendor, or
...

Software is so squishy.

         <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.