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

101–110 of 211 posts

Re: Pyston v2: Faster Python

#101

Post by sk2020 »

newen wrote: post #76
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.

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.

Re: Pyston v2: Faster Python

#102

Post by Narann »

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.

You're right, this objection is not relevant in general.

But in the situation we talk about, having 20 % more performance requires you to choose a fork that can came with it's own limitation. It's definitely not free.

This trade of makes the point about the language choice relevant.

Re: Pyston v2: Faster Python

#104

Post by mrtranscendence »

ak217 wrote: post #82
orf wrote: post #70

Earlier quoted context omitted.

https://github.com/markshannon/faster-cpython/blob/master/pl... And some discussion: https://news.ycombinator.com/item?id=24848318

Thanks - Mark Shannon is a core committer, right? So hopefully he has standing to get this done. The plan looks very high level at this point, but it looks like Mark is an expert in interpreter VM and JIT technologies. All I can hope for is that he doesn't get blocked by the "keep cpython simple" obstructionism.

He thinks (they think?) the project will need to be funded to the tune of $2M. That seems like a hefty sum to me, though maybe it's doable.

Re: Pyston v2: Faster Python

#105

Post by gnulinux »

sjansen wrote: post #35
beervirus wrote: post #19

20% isn't nothing... but is it really worth switching to a non-standard, closed-source version of the interpreter?

Depends on your scale. If each of your web servers has a hand picked name, definitely not. But if you stopped naming servers a long time ago, and if the pricing structure is favorable, it could mean a huge cost saving without an expensive rewrite.

What does it have to do with naming servers, can you explain? Or do you mean if you have very few servers such that you can name each and every one of them, this wouldn't be worth it?

Re: Pyston v2: Faster Python

#106

Post by hhas01 »

dragonwriter wrote: post #95
newen wrote: post #72

Earlier quoted context omitted.

I agree. Almost all arguments in favor of Python is about sunk cost. Not much about the actual language is appealing compared to modern languages.

> Almost all arguments in favor of Python is about sunk cost. I think you are confusing ecosystem and other established advantages with sunk costs, they are different things. It's true that (from the perspective of the people who built them), those advantages are the products of sunk costs, but the argument is about the ongoing value delivered, not the sunk cost involved in delivering it. > Not much about the actual…

“the argument is about the ongoing value delivered”

Which is an admirable sentiment… but the title of this thread is not “Python: still doing useful work” but “Python: now 20% faster”, and being ridiculously self-congratulatory about this when the correct response is to laugh at the silly pointless frivolity of it.

Trying to make Python fast is a fool’s errand, because Python is slow by design.

A useful argument would be that Python is faster overall at solving various real-world problems than current alternatives; but that’s not the popular argument being made, because the population fixates on minutiae instead of overall perspective.

Re: Pyston v2: Faster Python

#107

Post by mhh__ »

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

My gut feeling is that Python is just not safe or static enough to ever be worth trying to compete with (say) C++ with. Python sure is easy but I think the asymptotic cost of using it for a big project (in my hands at least) is just not worth it.

I like Python's syntax quite a bit but I feel bad watching people learn to program using it - partly because it's an oddly low-level language (It's closer to being C than Haskell) and there's no compiler to stop you shooting yourself in the foot (If I write something fundamentally unsound I want to know about it now not when the process has been running all day)

Re: Pyston v2: Faster Python

#108

Post by kazinator »

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.

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

Re: Pyston v2: Faster Python

#109

Post by omginternets »

mrtranscendence wrote: post #88
throwaway894345 wrote: post #58

Earlier quoted context omitted.

> I'd love to find a viable competitor to Python that's strictly better than it. I strongly recommend Go as a better Python. Personally, I think it's easier to write than Python (although people who care very little about correctness will be bothered a bit by the type checker), and the tooling is many times better (single-binary deployments, great dependency management, etc are awesome). Also, the performance is abou…

I'll be honest, as someone whose non-Python programming (paltry as it is) is mostly done in statically-typed functional languages, I have a bit of a bias against Go for the whole generics thing. I'll give it a closer look at some point.

I gotta be honest, the lack of generics has never bothered me.

The type-assertion escape hatch has always been largely sufficient for all but the most performance-critical projects (of which I have exactly 1, and it was a side project), and runtime panics due to failed assertions are quite easy to eliminate via wrapper types.

My advice: just go for it. You almost certainly won't miss generics.

(Edit: I've broken my own rule and given advice without first asking what kind of programming you do. My assertion holds for most run-of-the-mill stuff, e.g. writing REST interfaces, network servers, etc. If you're within 2-sigma of the industry, you won't miss generics.)

Re: Pyston v2: Faster Python

#110

Post by fnord123 »

rhencke wrote: post #54
saurik wrote: post #38

Earlier quoted context omitted.

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…

Google did not hire Rob Pike with Go in mind. Go did not even come around as an idea until Pike had worked at Google for a while. [1] Don't forget Rob Pike created Sawzall at Google first (2005). [2] [1] https://golang.org/doc/faq#history [2] https://research.google/pubs/pub61/

The early Go compiler reused the code generator from Limbo. To the point that many comments referred to Limbo. So while Rob Pike might not have joined Google to work on Go or had Go in mind, the idea and direction for Go was probably preordained.

It doesn't really support or attack your claims. It's just a thing I wanted to share.

Post reply on HN