[Python-Dev] Performance compares

[M.-A. Lemburg]

Tim Peters wrote:
> 
> [MAL]
> > How about making performance the main "feature" for 2.3 then ?!
> 
> Guido may be a dictator, but he doesn't have a magic wand -- "the main
> feature" is what people volunteer to do and then fight for and then actually
> do.

I will certainly go back to the basics and redo my optimization
patches for Python later this year. Whether or not these will
get included in the core is another story, but I have a need for
a fast interpreter for my app. server and can't afford losing
too much performance when moving from 1.5.x to 2.x.
 
> > 2.0 - 2.2 introduced many new features in the interpreter core,
> > so I think it's time to stabilize those features and focus on
> > making Python regain the performance it had before those features
> > were introduced.  At least to some of us, performance is an
> > issue and I think that there's a lot we can do to improve it.
> 
> "Performance" is meaningless unless quantified and made concrete:  what is it
> that runs too slowly?  "Everything" is not a useful answer.  Speeding up
> line-at-a-time input was an example of something that worked, via focus and
> measurement and pushing ahead despite opposition.  I doubt any other approach
> will bear fruit over such a short timeframe, and especially not without
> resources to throw at it.

Let's put it this way: if pystone gets a 50% boost, then all
applications should benefit from it regardeless whether they
are function call intense or fiddle with a lot of attributes.
Achieving those 50% will be a lot harder than for the 1.5
series, though ;-)
 
> > One way to open up the field for better performance will be
> > to modularize the interpreter, so that new ways of optimization
> > can be explored, e.g. truning the VM a register machine
> > (Skip once started looking into this with his Rattlesnake
> > patches) or creating specialized VMs which can then be used
> > by optimizing compilers as targets.
> 
> Restructure the core for the benefit of optimizing compilers that don't
> exist?  That sounds like an interesting research project, but not much to do
> with making 2.3 faster.  In the meantime, modularization is more likely to
> make the VM that does exist slower.

Depends on how you look at it: extension writers will then
have the possibility of plugging in new compilers and VMs
into Python to experiment with new optimization strategies.

The Rattlesnake project is one such project which would do
great with this plugin logic since it uses special opcodes
which an optimizer generates and then needs a modified VM
to execute these new byte code streams...

from Rattlesnake import compiler, vm
sys.use_compiler(compiler)
sys.use_vm(vm)

This won't make stock Python 2.3 faster, but at least provide
better means for experiments in that direction.
Alternative VM implementations like Stackless Python would 
also benefit from it.

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/