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

111–120 of 211 posts

Re: Pyston v2: Faster Python

#111

Post by omginternets »

chrisseaton wrote: post #21
pwinnski wrote: post #3

I feel like anybody really searching for speed is using something other than Python. I don't use Python for speed, but for ease-of-use. It took me some clicks to see it's supposed to be a drop-in replacement, so that's good.

> I don't use Python for speed, but for ease-of-use. Right - but if you can get that with better performance that's good isn't it? I don't get why people object to performance work on languages not intended for performance.

>I don't get why people object to performance work on languages not intended for performance.

It's simple, really. They're concerned about the trade-offs.

Re: Pyston v2: Faster Python

#112

Post by chrisseaton »

omginternets wrote: post #111
chrisseaton wrote: post #21

Earlier quoted context omitted.

> I don't use Python for speed, but for ease-of-use. Right - but if you can get that with better performance that's good isn't it? I don't get why people object to performance work on languages not intended for performance.

>I don't get why people object to performance work on languages not intended for performance. It's simple, really. They're concerned about the trade-offs.

If it's in a fork that you can pretend doesn't exist if you don't want it... what is the trade-off?

Re: Pyston v2: Faster Python

#113

Post by mkl »

kapilvt wrote: post #93
soperj wrote: post #16

Earlier quoted context omitted.

Project says: A faster and highly-compatible implementation of the Python programming language. The code here is out of date, please follow our blog

where is the code? the repo looks relatively untouched, the blog directs to this repo for filing issues. https://github.com/pyston/pyston

Pyston v2 is closed source (for now?). From the blog post:

> Our plan is to open-source the code in the future, but since compiler projects are expensive and we no longer have benevolent corporate sponsorship, it is currently closed-source while we iron out our business model.

Re: Pyston v2: Faster Python

#114

Post by ghj »

kmod wrote: post #77
ghj wrote: post #55

I stalked the author's linkedin and notice he has competitive programming experience: https://www.topcoder.com/members/kmod/details/?track=DATA_SC... (and top 15 putnam, ICPC world finals, etc) I wonder if he would be interested in optimizing for purely algorithmic tasks? There are a lot active and successful CPython and PyPy users on https://atcoder.jp/ . For example: https://atcoder.jp/contests/practice2/submission…

All my CodeJam solutions are in Python :) While we could certainly go in this direction, we're not planning to, because in our experience optimizations for different workloads are largely distinct, and this use case is already handled well by PyPy.

Isn't this use case the scientific computing use case? That's a fairly large part of the ecosystem to give up on!

I think it's still a relatively low effort way (just need to write a scraper) to create a benchmark on a diverse set of algorithmic tasks that have clearcut criteria on AC/TLE/WA. PyPy is often 10x faster than cpython on these problems (and just 2x slower than equivalent C++ solution) so it will be a much nicer headline too if you can achieve similar performances!

Though I can also see how it can be completely irrelevant for server workloads. Pypy's unicode is so slow, some people on codeforces still use pypy2 over pypy3 just to avoid it. And c extensions is so bad on pypy, you can often get better performance on cpython if you need to use numpy.

Re: Pyston v2: Faster Python

#115

Post by chrisseaton »

kazinator wrote: post #108
chrisseaton wrote: post #21

Earlier quoted context omitted.

> I don't use Python for speed, but for ease-of-use. Right - but if you can get that with better performance that's good isn't it? I don't get why people object to performance work on languages not intended for performance.

People object to changes in requirements and implementations that they don't control and don't perceive as being beneficial to their use case.

But it's a fork. And what do you mean by 'requirements'? It's compatible. Forget it exists if you don't want it.

Re: Pyston v2: Faster Python

#116

Post by bearzoo »

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…

many scientific computing applications are considered to be bounded by io

Re: Pyston v2: Faster Python

#117

Post by newen »

sk2020 wrote: post #101
newen wrote: post #76

Earlier quoted context omitted.

Numpy has a very poor API compared to Julia, Matlab, Mathematica, R. That’s just me comparing to the ones I know. It’s a mishmash of methods and functions, in-place operations and non-modifying operations, confusing indexing and broadcasting API. There are much better things available for array manipulation.

I like R, but there is nothing elegant or consistent about its standard library. I don’t think you’re making a good-faith argument.

Don’t just randomly accuse people of making bad faith arguments. I’ve use R a lot and while it has its issues, it has a much better interface than numpy.

Re: Pyston v2: Faster Python

#118

Post by attractivechaos »

hhas01 wrote: post #45
qorrect wrote: post #6

Earlier quoted context omitted.

I use python because of Numpy, Scikit and Tensorflow. I don't know of any other languages with libraries as productive as these, so speeding these apps up is a big win for a lot of people. Also 20% is huge, I look forward to trying it!

20% faster is nothing. You want at least a magnitude faster to justify the cost and risk of switching. The Python language is already 30 years old, and it wasn’t even the cutting-edge in imperative language design ( Smalltalk, Lisp ) back then. It’s positively antiquated now. I’ve never understood this tunnel-vision obsession with endlessly chasing ever-diminishing returns. It’s Zawinski's Law of Software by way of G…

Interesting that you are down voted. I agree with you that 20% faster is really nothing in comparison to the many new languages. I was saddened by the path Python3 chose. If compatibility was already broken at the time, they should have designed something with performance in mind from the beginning. The V8 javascript engine was there. We knew things could get >10X faster with JIT. Python is too big to die, but it is an inferior programming language in many ways.

Re: Pyston v2: Faster Python

#119

Post by N1H1L »

rrdharan wrote: post #17
dwheeler wrote: post #13

Earlier quoted context omitted.

As far as I know CPython is quite welcoming. However, per the blog post, this version of Pyston is closed source. So CPython won't be interested, and many others won't be interested either.

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 read the thread, it's from 2016. But hasn't numba made some big progress in JITting CPython?

Re: Pyston v2: Faster Python

#120

Post by N1H1L »

saurik wrote: post #38
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…

100% agree. To a very real extent, Go probably only exists at all because Google poured an infinite amount of effort into Unladen Swallow--a project designed to remove the GIL from Python 2 to make it more usable for concurrent programs and add an LLVM-based JIT compiler to improve performance--and Python's response was to not only not merge it, but to break the entire Python ecosystem for a decade by forking the lan…

The glue layers speedups are really bothering me. I absolutely fail to understand how a data science heavy language in 2020 can have such convoluted parallel processing. Dask, numba, joblib all are unfinished projects and absolutely not headache-free. CuPy works great, but it is not multi-GPU capable as of today.

And anytime you point this out, people will trot out a toy problem in Cython and try to prove you wrong, which has zero relevance to real world issues. Hell, Cython cannot even compile something as basic as Numpy FFTs, something that is absolutely critical in signal processing.

Post reply on HN