Modifying the Python object model • Hacker News Board

Re: Modifying the Python object model

#31

Post by mistrial9 » Sat, May 19, 2018, 6:16 PM UTC

eesmith wrote: post #22

mistrial9 wrote: post #20

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?…

> "argues against the TONE of the communication! during a fairly ordinary technical discussion of language implementation. The LWN piece says "Guido van Rossum, who loudly objected to Shapiro's tone, which was condescending, he said". That sounds appropriate. In your experience, do most people presenting an 'ordinary technical discussion' use a condescending tone? If so, I'm glad I don't work in your organization. Ot…

"Guido van Rossum, who loudly objected to Shapiro's tone, which was condescending, he said" yes, appropriate -and- appreciated

Re: Modifying the Python object model

#32

Post by sametmax » Sat, May 19, 2018, 6:20 PM UTC

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…

It's exactly that.

The Python ecosystem in general is severely underfunded despite all big players using it extensively, which makes it really unfair if you compare it to the money poured into JS because of its monopoly on the web.

Remember Unladen shallow ? "Google" attempt to JIT Python ? It was just one guy during his internship (http://qinsb.blogspot.fr/2011/03/unladen-swallow-retrospecti...).

And look at the budget the PSF had in 2011 to help the community: http://pyfound.blogspot.fr/2012/01/psf-grants-over-37000-to-.... I mean, even today they have to go though so many shenanigans for barely 20k (https://www.python.org/psf/donations/2018-q2-drive/).

But at the same time you hear people complaining they yet can't migrate to Python 3 because they have millions of lines of Python. You hear of them when they want to extend the support for free, but never to support the community.

It's ridiculous.

Python needs a sugar daddy. It's used in Mac and Linux. It's used at Microsoft, Google, Facebook, Nasa and so many more.

Re: Modifying the Python object model

#33

Post by acqq » Sat, May 19, 2018, 7:04 PM UTC

MR4D wrote: post #19

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 .

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…

> Going from 3 to 4 and getting a 50% speedup

That's way too low goal to even matter.

See this:

https://news.ycombinator.com/item?id=17007867

A simple loop in loop is 50 times faster in Javascript in the Firefox than the same loop in loop in Python. When you say "50% speedup" I understand you expect a speedup of 2 in "10 years". Before V8 the Javascript in Firefox was even slower than Python is now. And now it's 50 times faster than Python for "simple" things (which are actually the most important ones to be made faster). PyPy also proves that some code can be JIT-ed. One of the PyPy's problems is the "compatibility with libraries" part.

And yes, that kind of speedup like in Javascript is achievable in Python too. It's just a question of the right people being paid to do that. I've personally made some JIT compilers and I'm sure that Python can also have really useful faster interpreter and JIT. The approach of V8 for speeding up the "objects" as they are typically used and the calls can surely be applied to Python:

From the article: "The instrumented interpreter found that 70% of objects have all of their attributes set in the object's __init__() method."

As far as I know, V8 approach shines for such objects.

Also note that modern Javascript engines don't do only JIT or only interpretation, they adapt in runtime.

Re: Modifying the Python object model

#34

Post by quotemstr » Sat, May 19, 2018, 9:01 PM UTC

fijal wrote: post #8

It's maybe worth noting that richards is an "easy" benchmark. PyPy has been speeding it up quite significantly by about 40x for a long time. Those changes are necessary for improved performance, but not nearly good enough. PyPy does that and tons and tons of more stuff and it gets dismissed here as "provided only modest speedup on company workload", which means there is far more involved here than just attribute look…

Pypy doesn't work well with cpython modules. That makes it a non-starter, sorry.

Re: Modifying the Python object model

#35

Post by quotemstr » Sat, May 19, 2018, 9:04 PM UTC

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 .

> the unwillingness to drop C API

What are you talking about? The article is about the Python core dev group rejecting speedups that preserve C module compatibility for the sake of, uh, readability or something?

Re: Modifying the Python object model

#36

Post by fijal » Sat, May 19, 2018, 9:16 PM UTC

quotemstr wrote: post #34

fijal wrote: post #8

It's maybe worth noting that richards is an "easy" benchmark. PyPy has been speeding it up quite significantly by about 40x for a long time. Those changes are necessary for improved performance, but not nearly good enough. PyPy does that and tons and tons of more stuff and it gets dismissed here as "provided only modest speedup on company workload", which means there is far more involved here than just attribute look…

Pypy doesn't work well with cpython modules. That makes it a non-starter, sorry.

We have been addressing that for the last 3 years. Which CPython modules it does not work with for you?

That comment was about something slightly different though - even though richards is 40x faster, pypy still is not faster on some workloads (like instagram in their measurments), which makes me think that there are other forces at play.

Re: Modifying the Python object model

#37

Post by ris » Sat, May 19, 2018, 9:33 PM UTC

sandGorgon wrote: post #28

eximius wrote: post #25

Earlier quoted context omitted.

I think PyPy is relatively unused because of the difficulty in using C extensions written for CPython. With PyPy, everything will work until suddenly things go horribly wrong or the library you need is just not available (numpy). The work they've done is fantastic, it's just a very difficult situation.

Which is why I'm very excited about Graal Python ( https://github.com/graalvm/graalpython/blob/master/README.md ) It has the potential to bring an underlying framework which is built on industrial quality VM+JIT and it's primary goal is being compatible with the Scipy ecosystem at least ...Which is reason enough for unlimited optimism.

> industrial quality VM+JIT

I'll skip over this mostly, just wondering what exactly you mean about this and whether you consider LLVM not to be "industrial quality" seeing as the failed Unladen Swallow project based itself upon that and it didn't seem to get them anywhere.

> it's primary goal is being compatible with the Scipy ecosystem at least

Well... it's not like PyPy isn't "compatible" with the scipy ecosystem. It just has to use a lower-performing object access mode to use cpyext-based extensions, which I suspect is a compromise any JIT-based implementation will need to make to be able to make use of these more old-school extensions.

Ironically on the subject of "industrial quality" JITs, GraalVM is based upon the same meta-tracing interpreter ideas that were largely pioneered by PyPy.

Re: Modifying the Python object model

#38

Post by ris » Sat, May 19, 2018, 9:39 PM UTC

oscargrouch wrote: post #16

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?

From what I've seen, V8 is extremely wed to the javascript language model. I don't think it even has a concept of numbers that aren't javascript "numbers". Unless of course you go towards wasm territory, which I don't think is a territory particularly fun for dynamic languages.

Re: Modifying the Python object model

#39

Post by eximius » Sat, May 19, 2018, 9:47 PM UTC

fijal wrote: post #27

eximius wrote: post #25

Earlier quoted context omitted.

I think PyPy is relatively unused because of the difficulty in using C extensions written for CPython. With PyPy, everything will work until suddenly things go horribly wrong or the library you need is just not available (numpy). The work they've done is fantastic, it's just a very difficult situation.

FYI numpy both works these days and it's officially supported

Hm, it wasn't listed as functional in whatever list I looked at recently. I'll have to check it out again!

Re: Modifying the Python object model

#40

Post by ris » Sat, May 19, 2018, 9:57 PM UTC

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…

> My view is that the limitations are almost purely financial

Your view is wrong. Implementing highly optimized versions of different languages (which may from the layman's point of view look quite similar) is not completely comparable. Python is a much more dynamic language than javascript - huge amounts of the language are overridable object by object, even down to attribute access. Hell, even down to isinstance() behaviour. And these are all things that need e.g. deoptimization barriers added in the code fast path to check if xyz mechanism happens to have been overridden. Javascript doesn't even have operator overloading.

The PyPy team have put a lot of work into building a performant python implementation (there's your "fork" for you...) having to, from what I can tell, work through a lot of these issues with a good deal of ingenuity along the way.

Throwing money and/or "rockstar programmers" at projects isn't as wise as it always seems. Particularly when they don't seem to have significantly investigated the work of a team that's been working on the "fast python" problem for the last 15 years.