Psyco alternative
king kikapu
it seems that Psyco's author will not port it for the upcoming Python
3000 release :(
So, for us who use it we will continue to use CPython 2.5.x version
for some time to come. Is there an alternative to Psyco so i can have
a look at ?
Thanks in advance.
Paul Rubin
> it seems that Psyco's author will not port it for the upcoming Python
> 3000 release :(
I think the idea is it will be part of PyPy and you should use that.
king kikapu
I know that his efforts are on PyPy now but i do not know when PyPy is
going to be stable and if i can use it with my current "development
stack" (PyQt, Eric4 etc). I mean, i do not know if it will be possible
to "abandon" CPYthon and use PyPy instead.
Diez B. Roggisch
Currently? No way. It's *way* to slow.
Diez
king kikapu
Ok, i know this. The one that i do not know, is if, let'say, in 2
years it will be ready for seriously development, PyPy will aim to
"replace" CPython entirely ?? We are talking about an whole new
distribution ?
As for psyco, are there any alternatives to use now ?
Diez B. Roggisch
> years it will be ready for seriously development, PyPy will aim to
> "replace" CPython entirely ?? We are talking about an whole new
> distribution ?
Most certainly not. It's the goal of each language to finally become
self-hosted, and I hope we see that for python. But that's nothing that
will happen anytime soon (soon being at least half a decade), and most
probably not for the 2.x-versions.
> As for psyco, are there any alternatives to use now ?
Nope, but I heard through the grapevine that while it won't be supported for
all times to come, a new version is in the making.
But ultimately, the author says that the approach is flawed, so at *some*
point it will be discontinued. But that could be said about nearly
everything, couldn't it?
Diez
king kikapu
> > As for psyco, are there any alternatives to use now ?
>
> Nope, but I heard through the grapevine that while it won't be supported for
> all times to come, a new version is in the making.
Aha!! It seems you have better "sources" than me! :)
> But ultimately, the author says that the approach is flawed, so at *some*
> point it will be discontinued. But that could be said about nearly
> everything, couldn't it?
>
> Diez
It is a pity because this module *does* really solve some problems...
Jean-Paul Calderone
>> Ok, i know this. The one that i do not know, is if, let'say, in 2
>> years it will be ready for seriously development, PyPy will aim to
>> "replace" CPython entirely ?? We are talking about an whole new
>> distribution ?
>
>Most certainly not. It's the goal of each language to finally become
>self-hosted, and I hope we see that for python. But that's nothing that
>will happen anytime soon (soon being at least half a decade), and most
>probably not for the 2.x-versions.
PyPy is self-hosted and has been for some time (a year or so?). Maybe
you're saying that PyPy won't replace CPython for at least five years?
Could be; prediction is hard. ;) PyPy is between 1x and 3x slower than
CPython for a lot of things, which isn't so much of a difference. A
bigger obstacle is the availability of third-party extension modules
which currently must be re-implemented in order to be available on PyPy.
This could easily take half a decade without a full-time or otherwise
concerted effort.
Jean-Paul
Stefan Behnel
>>> As for psyco, are there any alternatives to use now ?
>> point it will be discontinued. But that could be said about nearly
>> everything, couldn't it?
>>
If it's about "some problems", then maybe Cython is an alternative.
Stefan
king kikapu
Hmmm...thanks but i think Pyrex-like solution is not the ideal one.
Coming from C# and having 8 years of expertise on it, i have gain a
very positive thinking about jit compilers and i think that psyco (ok,
a just-in-time specializer) is a more easy (and more correct) way to
go that mixing 2 languages.
bearoph...@lycos.com
> the author says that the approach is flawed, so at *some*
> point it will be discontinued.
Can't Psyco be improved, so it can compile things like:
nums = (i for i in xrange(200000) if i % 2)
print sum(nums)
I think the current Psyco runs slower than Python with generators/
iterators. To speed up that code with Psyco you have to write this:
nums = [i for i in xrange(200000) if i % 2]
print sum(nums)
Bye,
bearophile
Jean-Paul Calderone
>Diez B. Roggisch:
>> the author says that the approach is flawed, so at *some*
>> point it will be discontinued.
>
>Can't Psyco be improved, so it can compile things like:
>
>nums = (i for i in xrange(200000) if i % 2)
>print sum(nums)
>
Sure, it can be. That doesn't mean it will be. Someone has to do it. :)
One reason attention is going to PyPy instead of Psyco is that PyPy's JIT
doesn't require as much careful attention to support and maintain support
for features like generators.
Jean-Paul
king kikapu
>
> Jean-Paul
I had a look at PyPy, it, indeed, have a very long way to go so we can
consider it an alternative.
Paul Boddie
>
[Psyco maintenance and further development]
> Nope, but I heard through the grapevine that while it won't be supported for
> all times to come, a new version is in the making.
>
> But ultimately, the author says that the approach is flawed, so at *some*
> point it will be discontinued. But that could be said about nearly
> everything, couldn't it?
From what I've seen from browsing publicly accessible materials,
there's a certain commercial interest in seeing Psyco updated
somewhat. So, whether it gets discontinued depends on the usual
factors of satisfying a need and there being qualified and motivated
people to work on it.
Paul
king kikapu
Let's hope that this isn't going to happen (psyco dicontinued). But i
do not have positive thinking after an email i got for the author last
week. Unless something has changed...
Luis M. González
To see how it´s going, you can check this out: http://morepypy.blogspot.com/
king kikapu
Thanks, that is my source already!
Christian Tismer
> Diez B. Roggisch:
>> the author says that the approach is flawed, so at *some*
>> point it will be discontinued.
>
> Can't Psyco be improved, so it can compile things like:
>
> nums = (i for i in xrange(200000) if i % 2)
> print sum(nums)
Although my main goal is to support PyPy as much as possible,
I am currently taking a pause in favor of filling the gap
for psyco, supporting generators. The details are not yet
settled, maybe we choose to change the project name,
to avoid the author getting bugged with questions about
this extra stuff.
- chris
--
Christian Tismer :^) <mailto:tis...@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/
kib
> bearoph...@lycos.com wrote:
>> Diez B. Roggisch:
>>> the author says that the approach is flawed, so at *some*
>>> point it will be discontinued.
>>
>> Can't Psyco be improved, so it can compile things like:
>>
>> nums = (i for i in xrange(200000) if i % 2)
>> print sum(nums)
>
> Although my main goal is to support PyPy as much as possible,
> I am currently taking a pause in favor of filling the gap
> for psyco, supporting generators. The details are not yet
> settled, maybe we choose to change the project name,
> to avoid the author getting bugged with questions about
> this extra stuff.
>
> - chris
>
Maybe try Psychotic
http://code.google.com/p/psychotic/
I really like the screencast !
...sorry for the bad joke :)
sturlamolden
> PyPy is self-hosted and has been for some time (a year or so?).
This is technically not correct. PyPy is hosted by RPython, which is
not Python but a different language all together.
sturlamolden
> As for psyco, are there any alternatives to use now ?
When Cython has implemented all of Python's syntax, we can replace
CPython's compiler and bytecode interpreter with Cython and a C
compiler. Cython can be one or two orders of magnitude faster than
CPython.
Steve Holden
for Restricted. Thus and RPython program must of necessity also be a
valid Python program. Or do you know something I don't?
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
sturlamolden
> Hmmm...thanks but i think Pyrex-like solution is not the ideal one.
> Coming from C# and having 8 years of expertise on it, i have gain a
> very positive thinking about jit compilers and i think that psyco (ok,
> a just-in-time specializer) is a more easy (and more correct) way to
> go that mixing 2 languages.
The problem with Python, when we are talking out jit compilation, is
it's reliance on attribute lookups in hash tables. Java and C# do not
have dynamically bound attributes, and can implement classes using
vtables. Attributes cannot be rebound in Java or C#. A Python jit
cannot even do elementary optimizations like keeping an integer in a
register. This makes it a lot easier to make an efficient jit compiler
for Java or C#. Python is more like Common Lisp. There is no efficient
jit for Lisp. But there are very fast implementations that depend on
optional static typing (e.g. SBCL and CMUCL). That could be an option
of Python as well, by including something like Cython and a C
compiler. Any module that has a cdef is passed to Cython and CC
instead of the usual bytecode compiler and interpreter.
sturlamolden
> I believe, without the benefit of recent experience, that the R stands
> for Restricted. Thus and RPython program must of necessity also be a
> valid Python program. Or do you know something I don't?
That is correct. But RPython is not anything like Python, I would not
even call it a dynamically typed language. It is actually more like
Fortran 77 with a Python look and feel.
sturlamolden
> From what I've seen from browsing publicly accessible materials,
> there's a certain commercial interest in seeing Psyco updated
> somewhat.
YouTube uses Psyco.
Steve Holden
That seems a little harsh: it's Python-in-a-strait-jacket.
The fact remains that since RPython programs also run under the standard
interpreter (albeit a factor of maybe a hundred times more slowly) their
claim of self-hosting is valid.
sturlamolden
> That seems a little harsh: it's Python-in-a-strait-jacket.
>
> The fact remains that since RPython programs also run under the standard
> interpreter (albeit a factor of maybe a hundred times more slowly) their
> claim of self-hosting is valid.
What is the smallest subset of Python needed to make a Turing complete
computer language? And would you still call that Python?
Steve Holden
this by saying:
> On Mar 27, 4:44 pm, Jean-Paul Calderone <exar...@divmod.com> wrote:
>
>> > PyPy is self-hosted and has been for some time (a year or so?).
>
> This is technically not correct. PyPy is hosted by RPython, which is
> not Python but a different language all together.
I am simply pointing out that RPython is used for efficiency, not to do
things that can't be done in standard Python. Since everything that is
done in RPython can also be done, albeit more slowly, in standard
Python, the claim to be self-hosting is valid despite your disagreement.
In other words, you can take the PyPy translator and run it on CPython.
The fact that they choose to use restricted Python instead in their
"production" system is merely an optimization.
sturlamolden
> I am simply pointing out that RPython is used for efficiency, not to do
> things that can't be done in standard Python.
Yes. And if we only use a very small subset of Python, it would in
effect be a form of assembly code. Hence my comment about the Turing
complete subset.
Steve Holden
reply to your next post.
Jacob Hallen
This is pure FUD! PyPy is written in RPython, which is a pure subset of Python,
designed for writing interpreters in such a way that they can be translated into
source code for a static language and then compiled to machine code.
The translation toolchain, written in Python is used to create a binary image,
which is a full interpreter for the Python language. This binary image can
run the toolchain to generate another, identical binary image, which of course
also is a a full interpreter for the Python language.
This makes PyPy self hosting in every sense of the word.
The fact that the interpreter is written in RPython and actually runs as an interpreted
program under CPyton or a compiled PyPy is a useful implementation detail, adding
yet another aspect of self hosting that is not present in other systems that claim
to be self hosting.
PyPy btw, is alive and well. Work is progressing along 3 major fronts. One is supporting
real world applications, where we recently added support for ctypes and where we
are working on ensuring that a number of popular modules and frameworks run under PyPy.
Another major undertaking has been to improve execution speed without the JIT. We can
report that we are faster than CPython on some benchmarks, while slower on others. On the
average, I'd say that we still have some catching up to do. The third avenue that
is being pursued is the JIT. While a huge refactoring has been finished and the
results look very good, there are still many months of work to do before the
JIT can be used in production.
Jacob Hallén
--