[pypy-dev] pypy on Tim Bray's blog

[Jacob Hallén]

fredagen den 23 november 2007 skrev Jesus Cea:
> Martijn Faassen wrote:
> > Sure, you're right, that's true. See another mail where I give a better
> > description of what I mean with "done": something that motivates people
> > to use it in production.
> >
> > That said, I am of course also seriously interested in running existing
> > code on the PyPy platform.
>
> A lot of years ago I asked Armin Rigo about reactivating the virtual
> machine code in pysco. New versions of psyco only works in x86, but
> first ones were generating bytecodes for a low level virtual machine
> able to run in my Sparc's, for example. I was very impressed about th
> especialization thing.
>
> Five year ago, perhaps?.
>
> The answer was: "psyco is deprecated. Pypy is the future".
>
> Pypy project is impressive, but I can't yet benefice for psyco
> performance in my Sparcs. In fact I can't use pypy anything "real" yet.

I don't think people who look at the PyPy project from the outside understand 
what a tremendous undertaking it is. Psyco was an effort to make Python fast. 
Stackless was an effort to add extra flexibility. Jython was made to support 
a different platform. PyPy is working on doing all this and add much greater 
maintainability in the face of language changes on top of that. This is a 
much harder problem than the sum of the 4 aspects and it takes a huge effort 
to get it right.

We currently have an estimate that it will take another 82 man months before 
we have a version that is fully mature and a viable replecement for CPython.

A reasonable guess is that we would see the equivalent of approximately one 
full time worker on the project if we can't pay people to do the work. This 
would mean that we would be done in 7 years. Not a happy prospect.

With funding, there are enough people with relevant understanding of the 
project who could tackle the remaining tasks and be done in about one year.
This is why we are currently focusing on cleaning up the code base, so that we 
are presentable to prospective paying customers, rather than forging ahead 
with more JIT work, or targetting yet another processor family.

If you want JIT optimizations for the Sparc, your best option is to look at 
the work already done for the x86 and the PPC and do the same code generation 
for the Sparc processor. Your second best option is to find someone with 
in-depth knowledge about code generation for the Sparc to do it. Your third 
best option is to find someone who will pay members of the PyPy project to do 
the work. Otherwise I'm afraid it will have a priority which is lower than 
the tasks included in the 82 man months.

Best regards

Jacob Hallén