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

Pyston v2: Faster Python

blog.pyston.org

Post reply on HN
Print view View original

61–70 of 211 posts

Re: Pyston v2: Faster Python

#61

Post by willseth »

throwaway894345 wrote: post #51
sk2020 wrote: post #44

Earlier quoted context omitted.

Scipy has a poor performance ceiling? Numpy has a poor API? Compared to what? Eigen? Whatever the Scala guys use? That sounds kind of silly to me, especially when hardly anyone is actually CPU-bound, anyway.

WRT performance ceiling, I'm mostly talking about things like Pandas which eagerly evaluate and which aren't amenable to a parallel execution model (multiple threads operating on the same data frame with minimal contention). WRT poor APIs, I'm talking about things like matplotlib or pandas or etc that take a whole slew of arguments and try to guess the caller's intent by inspecting the types of the arguments. The ref…

"Based on prototypes I [spent a limited amount of time on and didn't research better methods], I'm confident..."

Re: Pyston v2: Faster Python

#62

Post by woeirua »

throwaway894345 wrote: post #29
rrdharan wrote: post #17

Earlier quoted context omitted.

Python is a welcoming community, but they are decidedly not welcoming of contributions that significantly increase the complexity of the CPython reference implementation. This has been discussed extensively: https://news.ycombinator.com/item?id=11125769

This is why I see little hope for Python, which is to say that while I'm sure it will continue to have a large following for many years a la C, C++, etc, I don't have hope for it being an exciting language or one that is particularly productive. Python already has performance and packaging problems which don't seem to be easily divorced from CPython, since virtually the whole reference implementation is depended upon…

I agree that packaging and dependency resolution can be a total nightmare at times. Anaconda helps to an extent, but it's far from ideal especially compared to the default options for other languages.

The main problem I have with Python is its maintainability, especially when you have multiple developers working in the same code base. I would never choose a dynamically typed language again to build something that is going to be more than several thousand lines of code, especially because of how it cripples your IDE which is essential for helping junior developers understand the existing codebase. Type hints help to an extent, but they're just a small bandaid over an oozing sore. Languages like Go are significantly better if you're going to build large codebases that need to survive for a long period of time.

Re: Pyston v2: Faster Python

#63

Post by ak217 »

orf wrote: post #47
rrdharan wrote: post #17

Earlier quoted context omitted.

Python is a welcoming community, but they are decidedly not welcoming of contributions that significantly increase the complexity of the CPython reference implementation. This has been discussed extensively: https://news.ycombinator.com/item?id=11125769

I might have to eat those old words as there is some form of runtime code specialisation being considered for inclusion in CPython. It doesn’t sound like a fully-fledged JIT, but that might be a distinction without a difference.

Link?

Re: Pyston v2: Faster Python

#64

Post by newen »

mrtranscendence wrote: post #49
throwaway894345 wrote: post #29

Earlier quoted context omitted.

This is why I see little hope for Python, which is to say that while I'm sure it will continue to have a large following for many years a la C, C++, etc, I don't have hope for it being an exciting language or one that is particularly productive. Python already has performance and packaging problems which don't seem to be easily divorced from CPython, since virtually the whole reference implementation is depended upon…

> Meanwhile, there are many other languages which are not only performant, but which are rapidly encroaching on Python's historically unique(ish) "easiness" What are those languages? I may have a blindspot, but the languages that get enough buzz for me to notice are either not competing with Python in important dimensions (e.g. Rust) or have a narrower focus (e.g. Julia). Elixir maybe? JavaScript and its derivatives?…

I think Julia is strictly better than Python, both for data oriented applications and for web development.

Re: Pyston v2: Faster Python

#66

Post by nickjj »

It's really awesome that it's not just a speed boost but a drastic decrease in memory usage too.

Going from a 230mb Flask app down to 55mb is huge if it's really a drop in replacement. If you factor in gunicorn process count, the wins are even higher because if you had 4 gunicorn processes each using 230mb but now they use 55mb, you're really going from 920mb down to 220mb of RAM.

Edit: This isn't true in the end, a brain malfunction mis-read the table thinking PyPy was actually the regular Python interpreter. It would be interesting to see how it compares to the default Python implementation for memory usage tho.

Re: Pyston v2: Faster Python

#67

Post by xapata »

throwaway894345 wrote: post #51
sk2020 wrote: post #44

Earlier quoted context omitted.

Scipy has a poor performance ceiling? Numpy has a poor API? Compared to what? Eigen? Whatever the Scala guys use? That sounds kind of silly to me, especially when hardly anyone is actually CPU-bound, anyway.

WRT performance ceiling, I'm mostly talking about things like Pandas which eagerly evaluate and which aren't amenable to a parallel execution model (multiple threads operating on the same data frame with minimal contention). WRT poor APIs, I'm talking about things like matplotlib or pandas or etc that take a whole slew of arguments and try to guess the caller's intent by inspecting the types of the arguments. The ref…

matplotlib and pandas were designed with the idea of mimicking interfaces more popular than the project (when they were first conceived). The "easy" interface is a large part of why those projects are now more popular then their inspirations.

Re: Pyston v2: Faster Python

#68

Post by visarga »

willseth wrote: post #57
throwaway894345 wrote: post #29

Earlier quoted context omitted.

This is why I see little hope for Python, which is to say that while I'm sure it will continue to have a large following for many years a la C, C++, etc, I don't have hope for it being an exciting language or one that is particularly productive. Python already has performance and packaging problems which don't seem to be easily divorced from CPython, since virtually the whole reference implementation is depended upon…

A different perspective is that Python leadership has been overwhelmed addressing the concerns of the enormous and growing Python community, for whom generally performance is not yet the primary concern - believe it or not. It's probably fair to suggest PSF has stumbled in executing some of their goals, most notably and publicly the transition to v3, but overall it seems like the general Python community is most inte…

Not just the package ecosystem, but you also have to have a large number of developers and jobs, so you can do hiring. Developing a project in a non-mainstream language means more difficult hiring.

Re: Pyston v2: Faster Python

#69

Post by cbsmith »

Can we talk about the name??

Like, if you wanted to create a confusing name, I can't think of worse ideas than naming it "v2" for a runtime that is Python 3 compatible, particularly for a project that has traditionally been Python 2 compatible...

Re: Pyston v2: Faster Python

#70

Post by orf »

ak217 wrote: post #63
orf wrote: post #47

Earlier quoted context omitted.

I might have to eat those old words as there is some form of runtime code specialisation being considered for inclusion in CPython. It doesn’t sound like a fully-fledged JIT, but that might be a distinction without a difference.

Link?

https://github.com/markshannon/faster-cpython/blob/master/pl...

And some discussion: https://news.ycombinator.com/item?id=24848318

Post reply on HN