Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PyPy v5.8 released

morepypy.blogspot.com

Post reply on HN
Print view View original

61–70 of 74 posts

Re: PyPy v5.8 released

#61

Post by brachi »

boultonmark wrote: post #9

I have a question and then a general vent 1. Does anyone know the latest update on NumPyPy? PyPy for me is just not a usable proposition because I heavily use Numpy (and Scipy et al). So I am forced to use slow Python + fast Numpy or slow Numpy + fast Python. Very saddening. The C-Extension is just so off the pace, NumPyPy was meant to solve that quandry. And I know some smart Alec will trot out the usual 'downshift…

You can read this great article just released about the Python 2017 language summit: "Keeping Python Competitive" [1]. There you can read opinions by many core developers. Pypy is also discussed

[1] https://lwn.net/Articles/723949/

Re: PyPy v5.8 released

#62

Post by [deleted] »

boultonmark wrote: post #9

I have a question and then a general vent 1. Does anyone know the latest update on NumPyPy? PyPy for me is just not a usable proposition because I heavily use Numpy (and Scipy et al). So I am forced to use slow Python + fast Numpy or slow Numpy + fast Python. Very saddening. The C-Extension is just so off the pace, NumPyPy was meant to solve that quandry. And I know some smart Alec will trot out the usual 'downshift…

[deleted]

Re: PyPy v5.8 released

#63

Post by gshulegaard »

boultonmark wrote: post #9

I have a question and then a general vent 1. Does anyone know the latest update on NumPyPy? PyPy for me is just not a usable proposition because I heavily use Numpy (and Scipy et al). So I am forced to use slow Python + fast Numpy or slow Numpy + fast Python. Very saddening. The C-Extension is just so off the pace, NumPyPy was meant to solve that quandry. And I know some smart Alec will trot out the usual 'downshift…

> And I know some smart Alec will trot out the usual 'downshift into C' line that everyone (including Guido) use as the final goto solution for performance but that is simply a disgrace in 2017.

Easy gluing of other languages together has long been something I considered a strength...but I suppose to each their own.

> Why can I not choose to write Python and it be fast??

Well there are lots of reasons...including implementation issues and I don't know them all...but I think Python has a very clear productivity niche. Personally, I am ok with Python trading performance for productivity. For the most part, I haven't had Python be so much of a bottleneck that writing a very small part of logic to be performant hasn't solved my use case.

> And yet Python 3 is getting slower. Don't agree?

Yeah I don't agree...that benchmark uses Python 3.3. The corner on Python 3 performance over Python 2 started turning around 3.4. Perhaps a talk from this years PyCon would help illustrate:

https://www.youtube.com/watch?v=d65dCD3VH9Q

> But PyPy is proof that Python can be fast.

Indeed, I would even say that Cython is even more proof that there are frontiers of performance that could be explored. But with PyPy (as with Cython) their are sacrifices you have to make.

Personally, I think the most promising performance improvement that is tantalizingly close for me is Larry Hasting's Gilectomy project:

> https://www.youtube.com/watch?v=pLqv11ScGsQ

But at the same time, I am not sure that Python ever needs to be fast running in CPython. With `WASM` perhaps it is better to just compile Python.

I don't know, performance in Python has always been a mixed bag...but personally I think it doesn't get much focus because it doesn't really serve Python's target niche. I don't know if there ever will be (or should) be 1 language to do everything...and as it is Python is a good "productivity" focused language to have in your toolbox so-to-speak.

Re: PyPy v5.8 released

#64

Post by neutronicus »

boultonmark wrote: post #9

I have a question and then a general vent 1. Does anyone know the latest update on NumPyPy? PyPy for me is just not a usable proposition because I heavily use Numpy (and Scipy et al). So I am forced to use slow Python + fast Numpy or slow Numpy + fast Python. Very saddening. The C-Extension is just so off the pace, NumPyPy was meant to solve that quandry. And I know some smart Alec will trot out the usual 'downshift…

Unlike you, Python is _not_ my favorite language, but the matplotlib lock-in is real.

Hopefully a matplotlib-equivalent will materialize on Clojure (where Linear Algebra is plenty fast and the language itself is fast-enough out of the box) so I can be done with Python forever.

Re: PyPy v5.8 released

#65

Post by ndc33 »

orf wrote: post #33
boultonmark wrote: post #24

Earlier quoted context omitted.

Ah the 'smart alec' has appeared. I'm not stupid, I know code like that won't be faster in Python but PyPy shows that it can be a hell of a lot faster than CPython and right up there with Node.js and the travesty is that CPython is so far off the pace and getting slower

I'm not a "smart alec" for pointing out that Python is, was and will be bad at heavily numerical, number crunching code. It's not what Python is built for. I mean... it takes 28 bytes to store a single integer in Python. > > sys.getsizeof(1) > 28

this is silly, python is used by some of the biggest number crunchers on earth ... as glue code. If you dont like the dual language paradigm and want fast code go learn fortran.

Re: PyPy v5.8 released

#66

Post by orf »

ndc33 wrote: post #65
orf wrote: post #33

Earlier quoted context omitted.

I'm not a "smart alec" for pointing out that Python is, was and will be bad at heavily numerical, number crunching code. It's not what Python is built for. I mean... it takes 28 bytes to store a single integer in Python. > > sys.getsizeof(1) > 28

this is silly, python is used by some of the biggest number crunchers on earth ... as glue code. If you dont like the dual language paradigm and want fast code go learn fortran.

Glue code being the important word in that comment.

Re: PyPy v5.8 released

#67

Post by takeda »

boultonmark wrote: post #9

I have a question and then a general vent 1. Does anyone know the latest update on NumPyPy? PyPy for me is just not a usable proposition because I heavily use Numpy (and Scipy et al). So I am forced to use slow Python + fast Numpy or slow Numpy + fast Python. Very saddening. The C-Extension is just so off the pace, NumPyPy was meant to solve that quandry. And I know some smart Alec will trot out the usual 'downshift…

If your code looks like this: https://github.com/MikeMirzayanov/binary-heap-benchmark/blob...

Then you probably should not use Python, python is more of a glue language which you should strive to make your program looking like a business logic, in real word to solve this problem you would write code such as this:

    import time

    if __name__ == "__main__":
        start = time.clock()
        N = 10000000
        h = list(range(N))
        h.sort()
        for i, v in enumerate(h):
            assert(i == v)
        print("Done in %f" % ((time.clock() - start) * 1000))

    $ python3.6 heap.py
    Done in 2389.877000
Or if heap needs to be used:

    import time
    from heapq import heapify, heappop

    if __name__ == "__main__":
        start = time.clock()
        N = 10000000
        h = list(range(N))
        heapify(h)
        for i in range(len(h)):
            assert(i == heappop(h))
        print("Done in %f" % ((time.clock() - start) * 1000))

    $ python3.6 heap.py
    Done in 10716.348000
Micro benchmarks are silly because you'll never do those things in real code.

Re: PyPy v5.8 released

#68

Post by dr_zoidberg »

dr_zoidberg wrote: post #44
lqdc13 wrote: post #8

Earlier quoted context omitted.

Blender Python lib by default is not optimized much. It has nothing to do with Python as a language. Use numpy for matrices. If you have to implement an algo with a hot inner loop, use cython or numba. I've never seen 100x difference in Python-C++ rewrite if Python was optimized already. Here is a good article about some of the options: https://rare-technologies.com/word2vec-in-python-part-two-op...

The one time I saw 100x increase in performance in Python-to-C (which was done through Cython) was in code that worked with strings calculating a machine-learning related distance between two strings. The code was doing a lot of accessing particular positions in the strings, which in pure python resulted in slow retrieval of every character (lots of .__getitem__ calls), which were optimized to having 2 predefined emp…

Just noticed after a while: it was "in the stack, not heap" (about the arrays).

Re: PyPy v5.8 released

#69

Post by mattip »

orf wrote: post #33
boultonmark wrote: post #24

Earlier quoted context omitted.

Ah the 'smart alec' has appeared. I'm not stupid, I know code like that won't be faster in Python but PyPy shows that it can be a hell of a lot faster than CPython and right up there with Node.js and the travesty is that CPython is so far off the pace and getting slower

I'm not a "smart alec" for pointing out that Python is, was and will be bad at heavily numerical, number crunching code. It's not what Python is built for. I mean... it takes 28 bytes to store a single integer in Python. > > sys.getsizeof(1) > 28

On PyPy, it can be many different sizes, including being completely optmized out. That is why PyPy has no sys.getsizeof

Re: PyPy v5.8 released

#70

Post by dang »

boultonmark wrote: post #24
orf wrote: post #23

Earlier quoted context omitted.

Newsflash: code like this[1] will never be fast in CPython, and if you write a lot of code like that and are sad when it's slow then you need a different language, especially if you expect it to be as fast as a JIT compiled language like js on v8. Or use something like Cython. That benchmark is pretty meaningless anyway, IMO. Here are some halfway decent, official and up to date benchmarks comparing python 2 and pyth…

Ah the 'smart alec' has appeared. I'm not stupid, I know code like that won't be faster in Python but PyPy shows that it can be a hell of a lot faster than CPython and right up there with Node.js and the travesty is that CPython is so far off the pace and getting slower

> Ah the 'smart alec' has appeared.

Would you please not post uncivilly to HN, regardless of how annoying you find someone's comment? This kind of thing degrades discussion and provokes worse from others. We're hoping to do better than that here.

Post reply on HN