

PyPy 2.0 beta 1 released - dagw
http://morepypy.blogspot.se/2012/11/pypy-20-beta-1.html

======
kkuduk
Regarding non-synthetic benchmarks, quite recently I've tested pypy as a
"backend" to Gentoo's package manager (portage). System was quite not up-to-
date, lots of packages and dependencies, this is how much time did it take
portage to figure out what to update:

    
    
      python2.7: 323.13s user 6.50s system 99% cpu 5:30.59 total 
      python3.2: 271.40s user 6.33s system 99% cpu 4:38.64 total 
      pypy1.9: 168.28s user 5.95s system 99% cpu 2:55.16 total

~~~
fijal
If you feel like providing such a benchmark for speed.pypy.org, we would be
very happy to accept it. I'm not sure how hard would that be though.

~~~
dbaupp
(Your benchmark site seems to be broken: <http://isitup.org/speed.pypy.org> )

~~~
fijal
it seems that it's just overloaded.

EDIT: back for now

------
alberth
How does PyPy 2.0 compares to LuaJIT 2.0 [1] with regards to memory usage and
performance?

I ask since they have similar goals for their respective languages.

[1] <http://luajit.org>

~~~
fijal
There is very limited data for non-artificial and non-numeric benchmarks for
Lua and Python, so treat it all with a grain of salt.

PyPy mostly cares about large scale programs (thanks to a large quantity of
Python libraries it's not that hard), while LuaJIT usually cares for smaller
stuff.

Last time I tried to run richards (which is the largest example I found for
both Lua and Python), PyPy was able to eventually outperform LuaJIT slightly,
given enough iterations, however LuaJIT warmup time was very very impressive
and it was much faster at the beginning.

From a very unscientific perspective I would expect LuaJIT to mostly
outperform PyPy, especially on stuff where it's feasible to compare, like by
implementing small numeric kernels in both Lua and Python, but I haven't
measured a whole lot in this area. LuaJIT definitely outperforms PyPy on the
computer language shootout benchmarks. I would also expect the field to be
more leveled if you implement say a webserver in both, caring about
performance, but this is really on the guessing side.

~~~
haberman
> PyPy was able to eventually outperform LuaJIT slightly, given enough
> iterations

Is this benchmark data-intensive? One known weak point of LuaJIT is its GC,
which is slated for a rewrite: <http://wiki.luajit.org/New-Garbage-Collector>

If "richards" allocates lots of objects that accumulate and need to be GC'd,
this could explain why PyPy wins eventually.

~~~
igouy
"[Richards] simulates the task dispatcher in the kernel of an operating
system."

[http://labs.oracle.com/people/mario/java_benchmarking/richar...](http://labs.oracle.com/people/mario/java_benchmarking/richards/richards.html)

~~~
haberman
That doesn't answer the question of whether the benchmark is written in a way
that generates lots of objects that need to be GC'd.

I'd be very surprised if PyPy beat LuaJIT for anything that was numerical or
otherwise had a fixed working set.

------
andybak
ARM, eh?

What's the memory usage like? That used to be a problem for anyone considering
PyPy on mobile chipsets.

~~~
firlefans
Also wondering about this, would be v. cool to play with it on iOS.

~~~
fijal
iOS does not allow you to run any sort of non-apple just-in-time compiler
(there is no public API to get executable mmaped pages to be precise), so a no
go, you cannot.

~~~
gsnedders
It's more than that: nothing outside of the built-in applications is allowed
to allocated executable memory at all. You can't even use JSC's JIT (i.e.,
that of Apple's JS engine) in third-party applications.

~~~
masklinn
> You can't even use JSC's JIT (i.e., that of Apple's JS engine) in third-
> party applications.

Although this very specific one may get fixed through remote views, which
apple is currently toying with (a webview would live in its own "webview
process" and thus embedded webview could finally get native JIT-ed speeds)

------
continuations
> Software Transactional Memory

Would pypy be able to take advantage of Haswell's hardware transactional
memory?

~~~
fijal
Not in the current incarnation, the HTM buffer is too small.

~~~
continuations
Is this specific to pypy or is the HTM buffer too small for most languages?
Are there any languages that will be able to use Haswell's HTM?

~~~
arigo
The HTM buffer is too small for any language for doing what I'm talking about,
which is long transactions. Haswell uses its L1 Data cache as buffer --- which
means at most 32KB or 64KB, and only if you're on a lucky day. (Actually it
depends on cache collision and alignment issues: it can in theory overflow
with only 9 memory accesses, but I'd expect the numbers to be generally more
than half the full cache size.)

The HTM buffer is big enough if the goal is "only" to remove the GIL. It's
going to be a 10-lines patch to CPython or PyPy (yes, really!). The GIL is
often made into a big issue, but in my opinion removing it isn't the final
solution to all multicore troubles in Python: that's just the first step.

------
realsmart
The OSX binary segfaults on a 64bit Lion. Can anybody confirm this?

~~~
fijal
I've seen at least 3 independent people saying that. We're investigating (it
works on OS X Mountain Lion though)

