Bytecode optimisation

[Christian Tismer]

Corran Webster wrote:
> 
> In article <m3k8u6aj7i.fsf at atrus.jesus.cam.ac.uk>,
> Michael Hudson  <mwh21 at cam.ac.uk> wrote:
> >cwebster at math.tamu.edu (Corran Webster) writes:
> >
> >I'm impressed (and slightly scared - people are actually *using* my
> >code...).

Of course, of course! :-)

> I think your code is potentially the most interesting development in the
> past few months - it has a _lot_ of potential.  A couple of other
> possibilities for using bytecodehacks which have occurred to me include:
> 
>   * A bytecode assembler - might give more speed in critical places
>     without having to go to C.  Also allow you to make Python dump
>     core when you mess up  :)
> 
>   * A back-end to John Aycock's little languages package to write
>     Python bytecode.  I haven't looked closely at this, so it may already
>     be done or easily done without bytecodehacks.  PyJava, anyone?

I don't see much evidence for a bytecode assembler.
Extending the bytecodehacks a little, to replace silly things
like constant tuple generation to something precompiled, well
if it's worth the effort.

But the bytecodes are designed to build a Python interpreter,
nothing else. The opcodes allow very few stack manipulations,
no stack addressing. You always push and pop things or load
and store them somewhere, but that's it.
You have also no way to spell access to known types.
You might remove lots of code by reordering, but that almost
removes stack operations, which are already the cheapest.

You can save lookups by semantic changes, as
the bytecodehacks do already.

But the majority of time sits in the C api, in the interpreter
itself, and in malloc (on Windows at least).

> >Have you looked at Skip Montanaro's optimizer:
> >
> >http://www.automatrix.com/~skip/python/spam7/optimizer.html

I could whine about all the good work he has put into it,
compared to the results.

...

> I'm well aware of this :)  It will require some amount of type-guessing,
> but since it'll need data flow analysis in any case, the additional cost
> may not be excessive.
> 
> Or as I mentioned in my reply to Mark-Andre Lemburg, there may be a case
> for an optimisation level which assumes sanity for many standard things,
> so that
> 
> for x in range(1000):
>   for y in range(1000):
>     do_stuff()
> 
> could assume that do_stuff() doesn't change the meaning of range and so
> this could be optimised to:
> 
> r = range(1000)
> for x in r:
>   for y in r:
>     do_stuff()

Looks promising in the first place. But you quickly realize
that this is no real optimization since you will do it
by hand, anyway, or use xrange.
And knowing if something is an xrange on every thousand's
run through the cycle, what does it help?

The loop opcode will anyway continue to call a sequence_getitem,
wether it knows the type or not.

> >if-you-get-better-than-twenty-percent-speed-up-I'll-be-impressed-ly y'rs
> >Michael

Guys, you are at the wrong end. This is another complete waste
of time. The whole interpreter overhead is bound to an average
of about 30 percent, when everything is C-code. I'd wonder if
bytecode optimization would give more than 15 percent on
average, when semantics are not changed.

Do little enhancements with moderate effort.
And check the optimization results of last year's
conference. It's overall pretty good work but disencouraging
results.

You need to invent special new bytecodes for the things
you want to optimize. If you can find and implement these, 
then it makes sense to optimize with type inference.

no-longer-optimizing-for-less-than-50-percent-ly y'rs - chris

-- 
Christian Tismer             :^)   <mailto:tismer at appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101   :    *Starship* http://starship.python.net
10553 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     we're tired of banana software - shipped green, ripens at home