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 _______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
