
PyPy 4.0.0 Released – A Jit with SIMD Vectorization and More - mattip
http://morepypy.blogspot.com/2015/10/pypy-400-released-jit-with-simd.html
======
BuckRogers
The 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
I'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
Not 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.

~~~
orf
Yeah, the best thing they could possibly do right now is to fork Python and
make yet another flavour. We already have this 2/3 mess so let's throw another
version into the mix just as Py2 seems to be dying.

I don't get this hate for Python 3. Yeah some things changed, yeah having a
big codebase in Py2 sucks if you don't have the time/resources to switch, but
starting new projects in Py3 by default is awesome. Asyncio and async/await
are fantastic and worth the switch alone.

~~~
vegabook
Yes, I agree that Python 3 is not that bad to start a new project in. But
that's not the problem. The problem is that many of us have a _huge_
investment in Python, and the project is meandering around, borderline-
insulting its historic users who still like 2.7, while simultaneously failing
to deliver on REAL needs such as performance and GPU support. Instead we get
these little tweaks here and there, downright embarrassing PEPs like type
annotations, and all this frankly distasteful pressure to move to 3.x using
threats of the end-of-the-line for 2....

Basically 3 gives us lots of headaches, very marginal improvements, an ivory-
tower sense of "we know best" (message to Guido - no you don't), and a real
concern that the powers that be have no clue what's going on at Golang Towers,
Fort Javascript, not to mention Clojure, Julia, or even Elixir.

------
wyldfire
Kudos 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.

~~~
pjmlp
> 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.

~~~
baldfat
We still are using FORTRAN for Business Applications and I fail to see the
need to switch them to a slower language to modernize them. Unless the switch
is solving a program leave them alone. This is why in R there is still plenty
of FORTRAN code.

Personally I LOVE Python but I always feel it is the 2nd best choice. I do use
Python but it rarely is the best tool to use for the problem you are solving.
Maybe Pypy will turn this around, and I hope so.

~~~
jzd
How can SciPy be fast if it is written in an interpreted language like Python?

Actually, the time-critical loops are usually implemented in C or Fortran.
Much of SciPy is a thin layer of code on top of the scientific routines that
are freely available at [http://www.netlib.org/](http://www.netlib.org/).
Netlib is a huge repository of incredibly valuable and robust scientific
algorithms written in C and Fortran. It would be silly to rewrite these
algorithms and would take years to debug them. SciPy uses a variety of methods
to generate “wrappers” around these algorithms so that they can be used in
Python. Some wrappers were generated by hand coding them in C. The rest were
generated using either SWIG or f2py. Some of the newer contributions to SciPy
are either written entirely or wrapped with Cython.

A second answer is that for difficult problems, a better algorithm can make a
tremendous difference in the time it takes to solve a problem. So using
scipy’s built-in algorithms may be much faster than a simple algorithm coded
in C.

[http://www.scipy.org/scipylib/faq.html#how-can-scipy-be-
fast...](http://www.scipy.org/scipylib/faq.html#how-can-scipy-be-fast-if-it-
is-written-in-an-interpreted-language-like-python)

~~~
semi-extrinsic
This is also why the scipy/numpy crowd doesn't care much about PyPy. In this
world Python is the equivalent of ducttape. You don't performance optimize
ducttape, you want it to be easy to use and to fix any problem you have.

~~~
camaraj
PyPy is taking a similar approach. The difference is Numpy is using CPython's
CAPI as the duct tape where as PyPy is using cffi as the duct tape. Both
approaches end up using the same underlying libraries.

Too many people just have the wrong impression, thinking that PyPy plans on
re-implementing all the libraries that Numpy and scipy use but that's just
completely false.

They have re-implemented the Numpy array so that it can take advantage of the
JIT and so that parts of an algorithm implemented In Python that uses Numpy
can also be optimized. Unlike what occurs when using Numpy under CPython where
the Python code does not get optimized unless it is converted to Cython, C
Code, or some alternative to Python to have it be optimized.

------
MatthewWilkes
> 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.

~~~
JulianWasTaken
This is very very disingenuous.

Here are the public IRC logs for what I assume you're referring to (which is
from July 2014 by the way):

[https://botbot.me/freenode/pypy/2014-07-02/?msg=17362202&pag...](https://botbot.me/freenode/pypy/2014-07-02/?msg=17362202&page=5)

You found a bug in an old version of PyPy. A core developer told you you might
want to try a new one. No one stole your shot out from under you.

You would undoubtedly be _welcomed_ to contribute. Don't post FUD.

 _Disclaimer: I am not a PyPy core dev but I do work closely with them._

~~~
Obi_Juan_Kenobi
> Alex_Gaynor - simpson: import operator; operator.isNumberType is the check
> you want

> I'll push this change quickly

> Alex_Gaynor - uhh, wait the check seems to exist?

I dunno, I kinda see both sides here. First, I don't think the devs were off-
base at all here. They were friendly and looking to solve problems. However,
they did seem to want to simply solve the problem, while Matthew did state
that he was looking at this as a way to contribute.

The whole interaction could have been improved with a little encouragement at
the end, and possibly a recommendation of an 'easy' bug that was currently in
need of a fix. It was fairly clear that there was an enthusiastic new
contributor, so a little effort in this direction may have been warranted.

I certainly would consider this an example of being unfriendly or unwelcoming.

------
gdulli
My 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
We 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
I'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.

~~~
fijal
Try builtin json instead of simplejson for pypy (it's API-equivalent)

~~~
dorfsmay
On big jobs (millions of json input/output) I have found ujson significantly
faster than json + pypy.

~~~
fijal
yop, as I said, ujson is probably your best bet if all you do is parse json.

~~~
sontek
If you are on python3 python-rapidjson is faster and safer than uJSON:

[https://github.com/kenrobbins/python-
rapidjson](https://github.com/kenrobbins/python-rapidjson)

    
    
        >>> data2 = 1.23456789e-13
        >>> rapidjson.loads(rapidjson.dumps(data2))
        1.23456789e-13
        >>> ujson.loads(ujson.dumps(data2))
        0.0

------
timeu
I 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
yes, 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
sounds 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
Have 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)

------
canjobear
It'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.

~~~
Beltiras
I 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
That'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
I was mostly getting a comparison between cpython and pypy, less concerned
with numpy vs cpython.

~~~
lqdc13
Sure, 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.

------
brachi
> 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.

------
baq
python 3.4 please ;_;

~~~
upofadown
The 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
most of my existing production code is 3.4, hence my question.

~~~
StavrosK
I'm/we are also moving everything to 3.4, since we want all the nice things.

------
Beltiras
According 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.

~~~
ericflo
You may be surprised, I've seen a lot of Django setups where template
rendering was the slowest or second-slowest part of their system behind DB
queries.

~~~
Beltiras
Still not spending a lot of time there due to proper fragment caching.

------
jordigh
I wish it had faster startup time, which really matters for Mercurial.

~~~
fijal
Working on it (even wrote 2 blog posts recently about it). Mercurial is an
interesting benchmark/use case for us.

~~~
jordigh
Yay! 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
[https://morepypy.blogspot.pt/2015/10/pypy-memory-and-
warmup-...](https://morepypy.blogspot.pt/2015/10/pypy-memory-and-warmup-
improvements-2.html)

[https://morepypy.blogspot.pt/2015/09/pypy-warmup-
improvement...](https://morepypy.blogspot.pt/2015/09/pypy-warmup-
improvements.html)

------
omginternets
Guys, what's a "trace optimizer"? Google is failing me by returning results
about MySQL.

~~~
pramodliv1
Search
[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_compilati...](https://en.wikipedia.org/wiki/Tracing_just-in-
time_compilation)

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.

------
trentnelson
How up-to-date is this? [http://doc.pypy.org/en/latest/windows.html#what-is-
missing-f...](http://doc.pypy.org/en/latest/windows.html#what-is-missing-for-
a-full-64-bit-translation)

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.

------
sontek
Is there any work going towards getting pandas to work with PyPy as well? Its
the only thing keeping me from using it.

------
mtw
Nice! Does this work with scipy now?

------
ryankung
so the next version of pypy3 should be 5.0.x, lol

