7 ms·
PyPy gets faster
- mikeklaas 16y agoYears and years later and they are finally able to (very slightly) beat psycho. Sigh.
- kingkilr 16y agoSure, but we have a 64-bit backend ;) After years and years still no one wants to write one for psycho. Edit: Psycho also broke Python's semantics in a few very subtle ways, in that sense it isn't a truly fair comparison.
- mikeklaas 16y agoHey, don't get me wrong, it's great that you're making strides, and I still hope the project is a success. My viewpoint comes as someone who was very excited initially at the thought of a drop-in replacement for CPython whose goal was to be "faster than c". It's been a very long time and it seems like pypy still has a long way to go to achieve production-readiness, so it's hard to continue being excited about the project.
- andybak 16y agoAside from the rapid performance gains in recent months and the fact that it's twice as fast as CPython...
- mikeklaas 16y ago... in these benchmarks, which are mostly tight-loop math code, from what I understand. Being a drop-in replacement also includes things like virtual crashproofness, full stdlib support, runs major third-party packages flawlessly, etc.
- Semiapies 16y agoThen don't be "excited". However, it's douchey to mock others' work just because they're not on your timetable.
- cool-RR 16y agoHow does Psyco break Python's semantics? I'm using Psyco for years and I didn't know that it did.
- kingkilr 16y ago2nd section here: http://psyco.sourceforge.net/psycoguide/bugs.html http://psyco.sourceforge.net/psycoguide/bugs.html
- snissn 16y agoPyPy needs epoll!
- kwellman 16y agoHas anyone done any recent memory benchmarks with PyPy? I'd like to see magnitude of the memory trade-off for using a JIT compiler. As a web developer my programs are mostly IO-bound, not CPU-bound. I'm also bootstrapping and trying to squeeze as much as I can out of my 512MB linode.
- kingkilr 16y agoPyPy's objects are smaller than CPython's, however the steady state interpreter is larger, and the JIT adds some additional overhead due to bookeeping and generated machine code.
- kwellman 16y agoPyPy is a very interesting project, but I suppose there's just no "killer feature" for me to start using it at the moment.
- silentbicycle 16y agoComparisons with LuaJIT (http://luajit.org/ http://luajit.org/) would be particularly nice.
- acqq 16y agoBut the speed difference is still too big. Even if PyPy is two times faster than CPython, LuaJit still remains in most of the cases the order of magnitude faster, they are comparable only when calculation bottleneck are bignum routines and not rest of the language: http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=python&lang2=luajit http://shootout.alioth.debian.org/u32/benchmark.php?test=all... In short, if you care about the speed and LuaJit is an option, the choice is obvious.
- igouy 16y agoUmmm, better to point to PyPy :: LuaJIT ? http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=pypy&lang2=luajit http://shootout.alioth.debian.org/u32/benchmark.php?test=all... Caveat - notice how many of those Lua programs were written by Mike Pall.
- fauigerzigerk 16y agoNot that I'm a big fan of Jython, but including startup time in a benchmark is only useful for very short running command line tools. It says nothing about the speed of the JIT or the code that's being tested.
- mzl 16y agoOn the other hand, there are a lot of small scripts and utilities that are written in Python, so it is a useful metric for quite a lot of use-cases.
- fauigerzigerk 16y agoI don't see why I would want to benchmark those kinds of utilities.
- ent 16y agothose utilities are often used shell scripted to run many times in a row. at least in interactive use, the multiplied startup times can grow annoyingly long.
- fauigerzigerk 16y agoYou could use one of those Java background daemons to do that, but anyway, what I was trying to say is just that this benchmark doesn't test JIT or interpreter performance in the case of Jython.
- mzl 16y agoBecause the start-up time of the interpreter will affect you every time you run one of those utilities.
- fauigerzigerk 16y agoSure, and I did mention command line utilities. The issue I see with the benchmark is that it compares apples and oranges. For some programs it tests JIT performance and for others it tests startup time. If I want to test startup time, I just use a hello world program. To test JIT/interpreter performance, I try to exclude startup time.
- random42 16y agoJust to be clear, what are the specified numbers? execution time in seconds?
- dripton 16y agoYes, execution time in seconds. And I throw out any program that fails on any Python, or takes longer than a minute on any Python.
- Raphael_Amiard 16y agoThat's really nice for PyPy. Although Eulers are mainly numerical tests. Most of the work done in many programmers "real world" are work on strings, which CPython is very good at since all its strings libs are implemented in C. So i'd like to see a comparison with a better benchmark i guess :)
- CWuestefeld 16y agoI'd like to see IronPython included in the comparison. (do they handle 2.7?)
- dripton 16y agoYes, I'll include IronPython next time. IronPython is at 2.6. PyPy and Jython are at 2.5. psyco is at 2.6. Most of my Euler solvers are compatible with Python 2.5. The ones that don't work in 2.5 end up getting excluded from the benchmark, because the benchmark only shows programs that worked and finished in less than a minute on every tested Python.
- deleted 16y ago[deleted]
- jnoller 16y agoCompetition in the python-vm space is fantastic and I'm actually really, really happy to see PyPy maturing.