Earlier quoted context omitted.
you should kickstarter this - and also the python 3 support.
we did kickstart the python 3 support on our website. Donate!
PyPy 4.0.0 Released – A Jit with SIMD Vectorization and More
91–100 of 150 posts
Re: PyPy 4.0.0 Released – A Jit with SIMD Vectorization and More
#92It'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.
I did a small test, here's the gist: 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.
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 loopRe: PyPy 4.0.0 Released – A Jit with SIMD Vectorization and More
#93Earlier quoted context omitted.
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…
I don't understand numerical analysis as business applications. For me business applications are what you would use Cobol, Clipper, Java, Delphi, C#, Eifel, .... Of course Fortran makes sense for number crushing, but that is the language domain, not doing CRUD, ETL or distributed computing stuff (not counting MPI here).
Accounting, spreadsheets, transaction processing, business intelligence?
Re: PyPy 4.0.0 Released – A Jit with SIMD Vectorization and More
#94The 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…
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.
Re: PyPy 4.0.0 Released – A Jit with SIMD Vectorization and More
#95Earlier quoted context omitted.
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.
Python 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.
Python3 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.
Re: PyPy 4.0.0 Released – A Jit with SIMD Vectorization and More
#96Earlier quoted context omitted.
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…
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/ . Netlib is a huge repository of incredibly valuable and robust scientific algorithms written in C and Fortran. It would be silly to rewrite t…
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.
Re: PyPy 4.0.0 Released – A Jit with SIMD Vectorization and More
#97I 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 ?
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.
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
Re: PyPy 4.0.0 Released – A Jit with SIMD Vectorization and More
#98Earlier quoted context omitted.
> 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.
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…
I like the quote: "Python is generally the second-best language for everything".
Re: PyPy 4.0.0 Released – A Jit with SIMD Vectorization and More
#99The 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…
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.
Not a bad idea. It would certainly elevate the project to unforeseen heights and probably turn them (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.
Re: PyPy 4.0.0 Released – A Jit with SIMD Vectorization and More
#100Earlier quoted context omitted.
Also I recently discovered that pypy supports non-ASCII characters pretty well which at least doesn't work with my version of python 2.7.6
In what way?
In variable names, for example. You can do this:
>>> π = 3.14
>>> π = 3.14
File "", line 1
π = 3.14
^
SyntaxError: invalid syntax