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

Modifying the Python object model

lwn.net

Post reply on HN
Print view View original

11–20 of 45 posts

Re: Modifying the Python object model

#11

Post by myWindoonn »

MR4D wrote: post #3

I would love to see python get much faster. Seeing all the work on node and V8 has made me jealous to the point of wondering if someone would ever take the Python syntax and just put it on top of V8 or (preferably) LLVM. Yeah, I know that’s more work that I can imagine, but I can dream, right?

Language implementations don't work that way. However, the PyPy JIT has been around for over a decade and works wonderfully. It is a continuing disappointment that only about 1-2% of the Python community knows about and/or uses PyPy.

(PyPy on LLVM has been a thing before. It requires constant upkeep and isn't very fast. I'm sure that the PyPy team would love to hear from prospective maintainers!)

Re: Modifying the Python object model

#12

Post by myWindoonn »

eximius wrote: post #4

Strange that Guido or the other CPython devs would object to adding caching (though, rereading, maybe they only objected to the tone it was presented in - which still seems a bit sensitive). I get favoring simple code over optimizations for more extreme cases like switching from dictionaries to arrays, but what essentially sounds like a tiny LRU cache for method dispatch seems like a clear win for everyone.

CPython has always strived to be a simple easy-to-read reference implementation of Python. They have rejected many patches over the decades which would have sped up various things at the expense of readability.

People should not use CPython for speed; they should use PyPy for speed.

Re: Modifying the Python object model

#13

Post by jimnotgym »

overgard wrote: post #10

I'm surprised the article left out mention of PyPy, which is pretty comparable to something like V8 http://speed.pypy.org/

> Thomas Wouters asked if he had looked at PyPy. Shapiro said the company had, but there was only a modest bump in performance for its workload.

It was mentioned, but in a rather dismissive way

Re: Modifying the Python object model

#14

Post by fijal »

overgard wrote: post #10

I'm surprised the article left out mention of PyPy, which is pretty comparable to something like V8 http://speed.pypy.org/

I believe the article is a more or less verbatim transcript of what happened. I wasn't there and I don't really want to speculate, but I would expect LWN to mention everything important that was mentioned and not add their own interpretation either.

Re: Modifying the Python object model

#15

Post by olskool »

fijal wrote: post #9
acqq wrote: post #5

Earlier quoted context omitted.

The development of V8 was paid for by Google, and at that point they wanted to achieve market dominance against other big players. It seems nobody is willing to put big enough money behind making Python much faster. My view is that the limitations are almost purely financial (as in, paying heavily somebody as skillful as e.g. Mike Pall or Lars Bak(1) and his team), not technical. If Guido would not accept the "faster…

The barriers are nearly purely social - the unwillingness to drop C API (or to have a phase out plan) and to declare certain kinds of behaviors as "implementation dependent" make it very hard for any meaningful competition to emerge. It is harder to make a fast python than to make a fast JS, but it's not that much harder .

> unwillingness to drop the C API

Is a feature not a bug. It makes things like NumPy, SciPy and Pandas possible.

Re: Modifying the Python object model

#16

Post by oscargrouch »

MR4D wrote: post #3

I would love to see python get much faster. Seeing all the work on node and V8 has made me jealous to the point of wondering if someone would ever take the Python syntax and just put it on top of V8 or (preferably) LLVM. Yeah, I know that’s more work that I can imagine, but I can dream, right?

I guess the TurboFan backend of V8 is so powerful now that my guess is that it would be prepared to receive a Python or Lua frontend to it.

Current Javascript is very complex, so maybe the current V8 Turbofan backend would already be fit to process a Python bytecode carefully crafted to fit this particular JIT backend?

Re: Modifying the Python object model

#17

Post by MR4D »

acqq wrote: post #5
MR4D wrote: post #3

I would love to see python get much faster. Seeing all the work on node and V8 has made me jealous to the point of wondering if someone would ever take the Python syntax and just put it on top of V8 or (preferably) LLVM. Yeah, I know that’s more work that I can imagine, but I can dream, right?

The development of V8 was paid for by Google, and at that point they wanted to achieve market dominance against other big players. It seems nobody is willing to put big enough money behind making Python much faster. My view is that the limitations are almost purely financial (as in, paying heavily somebody as skillful as e.g. Mike Pall or Lars Bak(1) and his team), not technical. If Guido would not accept the "faster…

I’m afraid that you might be right. I’d love to see Instagram step up to the challenge here, as they obviously have deeper pockets than most.

Who knows, maybe releasing their experimental code would prompt some really good discussion and get things moving in a direction of speedy run times.

Re: Modifying the Python object model

#18

Post by eesmith »

olskool wrote: post #15
fijal wrote: post #9

Earlier quoted context omitted.

The barriers are nearly purely social - the unwillingness to drop C API (or to have a phase out plan) and to declare certain kinds of behaviors as "implementation dependent" make it very hard for any meaningful competition to emerge. It is harder to make a fast python than to make a fast JS, but it's not that much harder .

> unwillingness to drop the C API Is a feature not a bug. It makes things like NumPy, SciPy and Pandas possible.

Aren't things like NumPy, etc. also possible through a FFI?

That is, I can understand that there's such a big installed based that people are loath to get rid of the Python/C extension API, but I think that's different than saying those projects are impossible without that extension API.

Re: Modifying the Python object model

#19

Post by MR4D »

fijal wrote: post #9
acqq wrote: post #5

Earlier quoted context omitted.

The development of V8 was paid for by Google, and at that point they wanted to achieve market dominance against other big players. It seems nobody is willing to put big enough money behind making Python much faster. My view is that the limitations are almost purely financial (as in, paying heavily somebody as skillful as e.g. Mike Pall or Lars Bak(1) and his team), not technical. If Guido would not accept the "faster…

The barriers are nearly purely social - the unwillingness to drop C API (or to have a phase out plan) and to declare certain kinds of behaviors as "implementation dependent" make it very hard for any meaningful competition to emerge. It is harder to make a fast python than to make a fast JS, but it's not that much harder .

I’m probably going to get crucified for this, but what the heck - open discussion on this topic is needed...

I like what you’re saying, but wonder if we made small incompatible changes over time, would that solve the problem? For example (and please forgive me on this), but there are so many similarities between Python and different languages. Objects are obviously everywhere - C++, Java, .Net, etc; and syntax’s are similar at a cursory glance to things like Fortran. All of the above are much faster.

We took a decade to go from Python 2 to 3, but that had some pretty big changes. Going from 3 to 4 and getting a 50% speedup while making some (hopefully small) incompatible changes would probably be a good motivator for people to migrate faster.

There are obviously pros and cons to this discussion, but i really believe that stagnation is the worst choice. (Ok, Perl made a worse choice, but I’m presuming we learned that the level of change from 2-3 is as far as we can go in a generational update (x.0) ).

Re: Modifying the Python object model

#20

Post by mistrial9 »

things that immediately come to mind: - GVR founder, involved and opinionated.. argues against the TONE of the communication ! during a fairly ordinary technical discussion of language implementation. Certainly a trained compiler implementor can carefully measure and then show becnhmarks on function dispatch.. but the concern raised has to do with maintainability of the code, more than raw performance. Dont you see? GVR is a humanist and social leader here. Ecosystem participation does matter, as well as raw tech specs. Hardcore math or performance languages are zillions of times faster, and how many users are there.. how many libraries..

* The fashionable inner-circle of the current economic winners, making the academic who "works for so-and-so" an immediate authority. Think for yourself! Wealth-makes-leadership leads to some sick outcomes, frankly. Sure, some academic compiler writer knows his function call stats, but that doesnt suddenly make the years and years of participatory work by many hands, less relevent. This is not populist, but rather pragmatic.

* Comparison to yet-another Python 3.x development. Great! Python evolves.. but lets not throw out a stable binary system with well-understood characteristics.. and that is.. Python 2.7

very interesting peek into the phenomenon of this language

Post reply on HN