PyPy 1.8 - business as usual

http://morepypy.blogspot.com/2012/02/pypy-18-business-as-usual.html

by bivab • 14 years ago

167 22 14 years ago

morepypy.blogspot.com

unwind• 14 years ago

Can somebody please fix the title? It hurts.

oinksoft• 14 years ago

I personally would like to know what business is like for the United States Ultralight Association.

Symmetry• 14 years ago

At first I thought it some some subtle dig at PyPy for not being feature complete or something.

RyanMcGreal• 14 years ago

I'd love to see a list of diffs: things that work in CPython and don't work in PyPy. That would be much more helpful for me to decide if it's time to switch.

ergo14• 14 years ago

"Everything should just work" - what might NOT work is other external libraries, like matplotlib, numpy,gevent etc.

ch0wn• 14 years ago

Here you go:

http://doc.pypy.org/en/latest/cpython_differences.html

http://pypy.org/compat.html

https://bitbucket.org/pypy/compatibility/wiki/Home

hencq• 14 years ago

Would the work on numpypy also make e.g. scipy available? Or would a separate effort be needed to move that to PyPy? Their website (scipy.org) mentions it builds on numpy, but it's unclear to me if it also depends on other libraries.

Edit: I see the scipy website also mentions this:

  Various SciPy modules use Fortran 77 libraries and some use C++, so you'll also need Fortran 77 and C++ compilers installed. The SciPy module Weave uses a C++ compiler at run time.

So I guess it wouldn't work out of the box. Do the PyPy devs have any plan for this as well?

fijal5• 14 years ago

This is an example approach how this might work - http://morepypy.blogspot.com/2011/12/plotting-using-matplotl...

obtu2• 14 years ago

This one is a great big hack…

cdavid• 14 years ago

scipy only depends on numpy, but both at the python and the C level (i.e. it uses the numpy C API).

mynegation• 14 years ago

PyPy to me looks like a great effort and a technological tour de force. But I wish they would talk _more_ about why and when PyPy will be _slower_ than CPython on their site . Here is why.

I tried to run some of my scripts on PyPy and performance was invariably worse (about 50% worse). And my first reaction was: PyPy is not delivering on its promises. Only later, on some forum I read that PyPy does not perform well on large dictionaries (and this is essentially what I do in my scripts). Have I known it in advance, my first impression of PyPy would be much better.

fijal5• 14 years ago

It's the creation of large dicts to be precise. The thing is we try to attack those problems as they arise and as people report bugs. Generally pypy slower than cpython is a bug and we consider it as such. That also means that those are moving targets usually - as we discover this, we fix it and sometime maybe something else pops up. It would be a bit of a mess to keep the list of such things on the website.

scott_s• 14 years ago

Do you have a web-facing bug tracking system?

sb• 14 years ago

In yesterday's "Fast VM" thread I asked about memory consumption of PyPy vs. CPython, because most of the benchmarks focus on speed and there usually are no memory consumption figures (iirc, they were huge for Unladden Swallow [~800megs on one of their benchmarks, probably the django benchmark]). While I agree with fijal that there are no benchmarks stressing the memory sub-system, I think it would also be interesting for many potential early adopters to know about expected requirements.

rplnt• 14 years ago

If I remember correctly then working with big integers (Python has "unlimited" integer) was really slow with pypy. My first example I ran in pypy used those and I was wondering what I did wrong when pypy is so slow compared to cpython.

reuser3• 14 years ago

I'm very amused that someone else has observed this about PyPy, I began to think I was the only one. It does not seem to be the orthodox view.

I like CPython's fast startups and low memory overhead, bad scores in Pfannkuch benchmarks notwithstanding. If PyPy runs my everyday stuff better to casual inspection I will get a different impression, but as things stand I see it as a kind of Java-ization whose superiority is often unclear or qualified.

Is a JIT always better? Is reference counting always worse? Is it a total no-brainer to want Software Transactional Memory? I don't think so. But I think there are some arguments, and perhaps as importantly I think there are many newer Python folks who want to make a name for themselves.

fijal5• 14 years ago

http://bugs.pypy.org, what can I say. Also "Is X always better than Y" is very often false for large enough domains.

fijal5• 14 years ago

After a bit of debate - this is actually a good idea, I'll make sure it's on the pypy website.

PyPy 1.8 - business as usual

Related Stories