14 ms·
PyPy 4.0.0 Released – A Jit with SIMD Vectorization and More
- timeu 11y agoI am curious. Usually in numpy basic linear algebra are delegated to BLAS and potentially really fast if configured to use a fast BLAS implementation (OpenBLAS, MKL, etc). Does the numpy fork of PyPy use the same approach ?
- fijal 11y agoyes, but BLAS only helps you with some operations and not others. In fact most of "basic" operations are still done "by hand" in some templated C in numpy. Additionally, doing vectorized operations lazily (which is not present right now in pypy but was at least considered in the past) yields great improvements.
- timeu 11y agosounds great. I have a scientfic library that relies on a mix of loops and matrix multiplication. I need to find some time to test it with PyPy
- pwang 11y agoHave you also checked out Numba? JIT and type inference, but native to CPython and designed for numerics: http://numba.pydata.org http://numba.pydata.org
- mattip 11y agoyes. However the delegation only happens if you use the numpy.linalg module, or if numpy has chosen internally to call the numpy.linalg module (i.e. logic in numpy.dot will call out for large ndarrays) Our vectorizing JIT can use SIMD semantics on all numpy looping calls. For instance, non-matrix multiply A*B or for ndarray + scalar calls While many numpy users are in the habit of manipulating large square matrices, there is a significant number of users who use small arrays, or process RGB pixels
- wyldfire 11y agoKudos to the pypy team! I suspect pypy would benefit from some kind of marketing campaign. It rarely lets me down and yet lots of python devs don't know about it. The most popular package(s) that don't work with it have been numpy, scipy, etc. When I first encountered pypy, there was a numpypy and I wouldn't be surprised if that's different now. But bottom line, tons of python code out there needs more performance and has no dependency on numpy or any C extensions.
- fijal 11y agowe're trying to address both numpy and C extensions, stay tuned ;-)
- wyldfire 11y agoKeep up the good work!
- sandGorgon 11y agoyou should kickstarter this - and also the python 3 support.
- pjmlp 11y ago> But bottom line, tons of python code out there needs more performance and has no dependency on numpy or any C extensions. What they need is nice JIT engines like PyPy and not to switch languages. If no one invested in improving implementations for modern languages and switched to something lower level all the time, we would still be using Fortran for business applications.
- baq 11y agopython 3.4 please ;_;
- upofadown 11y agoThe value of PyPy is that it is a thing you can just drop in to make your code faster. If PyPy wants to gain any traction they pretty much have to concentrate on the version with the most existing code.
- baq 11y agomost of my existing production code is 3.4, hence my question.
- StavrosK 11y agoI'm/we are also moving everything to 3.4, since we want all the nice things.
- ciupicri 11y agoPython 3 is the future. There's a chance that when Pypy finally catches up with Python 2.7 (numpy, C extensions etc), it will be obsolete.
- upofadown 11y agoPython3 is a language. Python2 is also a language. Python3 might someday become wildly popular, but that doesn't magically make Python2 go away just because the name sounds the same.
- ciupicri 11y agoFrom [PEP 373]: > The End Of Life date (EOL, sunset date) for Python 2.7 has been moved five years into the future, to 2020. This decision was made to clarify the status of Python 2.7 and relieve worries for those users who cannot yet migrate to Python 3. See also PEP 466. > This declaration does not guarantee that bugfix releases will be made on a regular basis, but it should enable volunteers who want to contribute bugfixes for Python 2.7 and it should satisfy vendors who still have to support Python 2 for years to come. > There will be no Python 2.8 (see PEP 404). Take note that the initial date was set to 2015 [2] and it was delayed only last year. [PEP 373]: http://legacy.python.org/dev/peps/pep-0373/ [2]: https://hg.python.org/peps/rev/76d43e52d978
- MatthewWilkes 11y ago> We would also like to thank our contributors (7 new ones since PyPy 2.6.0) and encourage new people to join the project. PyPy has many layers and we need help with all of them This doesn't match my experience of the PyPy project. I found a tiny bug in the stdlib matching against CPython, went into IRC to ask a question about test running to be sure I got it right and was quickly engaged in conversation about why I was running core tests. Next thing I know my small bug has been fixed by a core developer and my chance to contribute is gone. I'll stick to being a user.
- ragebol 11y agoIs this a complaint or a compliment to the developers?
- MrBuddyCasino 11y agoHe didn't want to report a bug, he wanted to contribute to the project. I can think of a few reasons why. They lost a new potential committer by "being pragmatic" about it, but ignoring inter-personal relationships, like so often.
- forgotpwtomain 11y agoPersonally I'd be quite excited to see a bug I reported fixed the same-day - of course people's expectations are different it's not always easy to balance these things.
- dorfsmay 11y agoOne of the rewards of participating in OSS is to make your name visible, this can then be used as creds to gain commit rights or to talk at conferences as well as proof of competence when looking for a job. Interestingly, I've had the same experience when reporting and asking how to contribute to Python 3, not by a core dev but somebody "stealing" my bug and quickly submitting a patch!
- omginternets 11y agoGuys, what's a "trace optimizer"? Google is failing me by returning results about MySQL.
- pramodliv1 11y agoSearch https://www.google.com?q=trace+optimizer+compilers https://www.google.com?q=trace+optimizer+compilers According to wikipedia: https://en.wikipedia.org/wiki/Tracing_just-in-time_compilation https://en.wikipedia.org/wiki/Tracing_just-in-time_compilati... Tracing just-in-time compilation is a technique used by virtual machines to optimize the execution of a program at runtime. This is done by recording a linear sequence of frequently executed operations, compiling them to native machine code and executing them. This is opposed to traditional just-in-time (JIT) compilers that work on a per-method basis.
- Nyetan 11y agoThey're referring to a tracing JIT[1], I believe. [1]:https://en.wikipedia.org/wiki/Tracing_just-in-time_compilation https://en.wikipedia.org/wiki/Tracing_just-in-time_compilati...
- shellac 11y agoI assume it's a reference to tracing JIT (https://en.wikipedia.org/wiki/Tracing_just-in-time_compilation https://en.wikipedia.org/wiki/Tracing_just-in-time_compilati...). It's a JIT that traces runtime execution, rather than looking at whole method or function bodies. In particular it eliminates control flow, which simplifies optimisation.
- DasIch 11y agoTraces are an artifact produced by some JITs. Basically you observe loops and loops that satisfy certain criteria are traced, that is all operations performed within one iteration are stored. Such a trace is then optimized, compiled to machine code and then executed for every iteration when the loop is encountered again.
- brachi 11y ago> We would also like to thank our contributors (7 new ones since PyPy 2.6.0) That's very good news, since monetary contributions don't seem to be abunding (none of the goals have been met according to pypy.org). Maybe it's a marketing issue, like said before? Thanks for all the effort made.
- jordigh 11y agoI wish it had faster startup time, which really matters for Mercurial.
- fijal 11y agoWorking on it (even wrote 2 blog posts recently about it). Mercurial is an interesting benchmark/use case for us.
- jordigh 11y agoYay! Glad to hear it. Using Python makes me so envious of Perl's startup time. Maybe some day we can have that in Python too... Where are those blog posts?
- fijal 11y agohttps://morepypy.blogspot.pt/2015/10/pypy-memory-and-warmup-improvements-2.html https://morepypy.blogspot.pt/2015/10/pypy-memory-and-warmup-... https://morepypy.blogspot.pt/2015/09/pypy-warmup-improvements.html https://morepypy.blogspot.pt/2015/09/pypy-warmup-improvement...
- deleted 11y ago[deleted]
- craigds 11y agoAre there recent analysis/benchmarks of startup time? This is the major blocker preventing us switching to PyPy, since we run a lot of short-lived processes.
- gdulli 11y agoMy experience with PyPy was that it was faster for mapreduce jobs without JSON parsing and slower for JSON-heavy jobs. Because, I assume, CPython benefits from a C implementation of simplejson and PyPy doesn't. Does anyone know if this has changed? (I'll probably install 4.0 and see for myself, but curious if anyone knows what I should expect.)
- fijal 11y agoWe did put some effort into making built-in json faster. If you're using an optimized version like uJson, it'll be faster under cpython so far, but it all depends whether there is more processing or more parsing involved. We're happy to help you with benchmarks though
- gdulli 11y agoI've only used simplejson. A mapreduce job could be reading billions of lines and possibly doing very simple logic on each line, so the parsing/encoding is a big percentage of the processing, sometimes nearly all of it. I'll try 4.0 and see how it does now.
- canjobear 11y agoIt's hard to tell from these posts under what circumstances will SIMD vectorization kick in outside of numpy. E.g., will it work for plain old list comprehensions, which are everywhere in my code? That would be awesome.
- fijal 11y agoGenerally speaking "no", but there are a few cases where it might, e.g. if you're using arrays/numpy arrays in list comprehensions. We could not get it to run on normal lists for a bit obscure reasons.
- Beltiras 11y agoI did a small test, here's the gist:https://gist.github.com/arnists/a9f19af5d9469549020e https://gist.github.com/arnists/a9f19af5d9469549020e Seems like a huge improvement, don't know if it's the recent additions or in general pypy vs cpython but it's enough of a speed bump to sit up and take note.
- lqdc13 11y agoThat's why you don't use pure python for this. Here is your test done using numpy import numpy as np %timeit sum(np.sum(np.random.randint(0, 10000000, 5000)) for i in range(5000)) 1 loops, best of 3: 586 ms per loop
- Beltiras 11y agoI was mostly getting a comparison between cpython and pypy, less concerned with numpy vs cpython.
- lqdc13 11y agoSure, but my point is that it's not a relevant comparison. A relevant comparison is counting words or something like that. Things people don't have an easy way to do much faster.
- Beltiras 11y agoAccording to data I'm getting a 20X performance increase from the rendering engine in Django. I know this is the least of the time I spend but it's significant enough to take a deeper look.
- mtw 11y agoNice! Does this work with scipy now?
- ryankung 11y agoso the next version of pypy3 should be 5.0.x, lol
- BuckRogers 11y agoThe good news never stops with these guys. PyPy is so good that I've stopped considering myself a "Python programmer" to a "PyPy programmer" over the last few years. Best of every world. I get my preferred language and eliminate CPU performance worries. For me, targeting development on PyPy has taken the place of migrating to Python3. Which just moves too fast in effort to pull people over, Python is too big for that strategy. At this point, people want speed with a great language, they want PyPy! The PyPy team has pretty much enabled the perfect development stack. I use PyPy+Django+gunicorn+Nginx and no problems. Keep up the great work.
- vegabook 11y agoI'll go one step further and advocate for the PyPy developers please not to port to Python 3. Here we have a project which has clearly become the go to for 2.x people who would like Python to move forward in a way which makes a real difference to them, and there is an ideal opportunity here for this to become the de-facto continuation of the 2.x line, with a real future, as an alternative to the 3.x forcefeed.
- BuckRogers 11y agoNot a bad idea. It would certainly elevate the project to unforeseen heights and probably turn them (http://www.baroquesoftware.com/ http://www.baroquesoftware.com/) into very wealthy men while offering a very desired and needed service for many businesses. While harming no one who didn't already harm themselves. More relevant than CPython3 overnight, which is of significant stature. If prestige and money are desirable things, absolute no brainer if they have a business bone in their bodies. It would also secure the future of the stack for everyone concerned with Python3 threatening to cut off Python2. It could also enable a bigger return on those of us who have invested financially into PyPy development. It would certainly snowball even more financial investment. It would then be the CPython3 project's move. Abandon and integrate all the non-breaking Python3 features into 2.7? Or just move forward with a significantly weaker and less relevant project, working against their past selves? I don't think most would really care and it's best they just move away with their own project. Could be on the way judging from the favorable naming convention, PyPy4? Has a nice ring to it. "the Python2.7 compatible release — PyPy 4.0.0 — (`what's new in PyPy4.0.0?`_)" "the Python3.2.5 compatible release — PyPy3 2.4.0 — (what's new in PyPy3 2.4.0?)." The PyPy gods are in an enviable position for sure. If they seize the opportunity it's the chance of a lifetime.
- sontek 11y agoIs there any work going towards getting pandas to work with PyPy as well? Its the only thing keeping me from using it.
- trentnelson 11y agoHow up-to-date is this? http://doc.pypy.org/en/latest/windows.html#what-is-missing-for-a-full-64-bit-translation http://doc.pypy.org/en/latest/windows.html#what-is-missing-f... I've read that a few times and I always come away confused -- it sounds like a huge fundamental type change needs to be made by someone well versed in the PyPy internals. i.e. not something you'd typically defer to an external contributor. I'd like to experiment with PyPy and PyParallel, but I'm basically exclusively 64-bit Windows, so it sounds like a non-starter.