[pypy-dev] a faster Python not a primary goal of PyPy?

[Christian Tismer]

Carl Friedrich Bolz wrote:

> Hi Martijn,
> 
> since I am in a very nitpicking mode...
> 
> Martijn Faassen wrote:

...

>> "The PyPy project aims at producing a flexible and fast Python 
>> implementation. The guiding idea is to translate a Python-level 
>> description of the Python language itself to lower level languages. 
>> Rumors have it that the secret goal is being faster-than-C which is 
>> nonsense, isn't it?"
> 
> 
> Note that it says "fexible and fast": fexible comes first. And we 
> explicitely say that the faster-than-C goal is nonsense.

I don't think that order is relevant in a mathematical "and".
For me it means "flexible without being slow" and
"fast without being inflexible".

This is the matter of optimization. We have seen examples of both.
Python is a quite fast, inflexible implementation. PyPy is a very
flexible but yet slow implementation.

The proof of concept, that we can have both at the same time, is
still not there.

And I don't support the nonsense part at all. Psyco has proven that
it can make CPython much faster under circumstances. The same
factor can be at least expected for PyPy. But if PyPy does not
jump over its current factor 40-50 hurdle, this acceleration
might still not outperform CPython.

...

> Holger's statement is very important. At the moment most people have the 
> notion that PyPy is mainly about speed. But the really exciting fact 
> about PyPy is its flexibility, therefore it makes sense to advertise the 
> flexibility goals a bit (even if that means diminishing the speed goal 
> in one single mail to pypy-dev). Of course, achieving high speed is a 
> worthwhile goal but this goal can be reached _because of_ the 
> flexibility of PyPy (not the other way round).

The impression of mostly being about speed might also come from the fact
that speed is the thing that PyPy lacks at most, hurtingly. And it is
clear if a project is started in the most flexible way possible from
the ground, with no consideration of speed at all. We will need to find
yet another stone of the wise to morph the code reasonably.
As said, I very much hope it, while there is currently no indicator
that we are close to it.

We have to prove that last point about flexibility. The gap lies in
the needed transformations, which need to be invented.

cheers - chris

-- 
Christian Tismer             :^)   <mailto:tismer at stackless.com>
tismerysoft GmbH             :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/