
Modifying the Python object model - Delgan
https://lwn.net/SubscriberLink/754163/a38214c50e7b3ece/
======
fijal
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 lookup/function call which have
been massively speed up by pypy for quite a few years now.

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

~~~
fijal
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.

~~~
quotemstr
Well, right now, I simultaneously want to use the python-gobject stuff,
Pandas, numpy, bcolz, and other assorted parts of the scipy universe.

------
eximius
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.

~~~
myWindoonn
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.

~~~
eximius
And it is simple. I haven't written C since college and it's mostly very
readable, really great for exploration. In many ways, I agree that should be
kept.

But memoizing lookups can be a single branch at the top of a few functions. We
should strive to have our cake and eat it too, not simply declare we shouldn't
bother.

~~~
xapata
It ain't that easy (cache invalidation is hard). But they did it anyway, so,
yeah, you can have your cake and eat it.

------
MR4D
Great article worth reading for any hardcore Python fans.

I’d also add that the comments on the LWN article are good too.

~~~
hodgesrm
LWN.net articles are generally quite good. I signed up after reading an
excellent summary of Spectre/Meltdown work from Greg Kroah-Hartmann.

@all if you like this article please pay for a subscription. LWN.net deserves
our support.

~~~
bakery2k
> LWN.net deserves our support.

Agreed. I subscribed a few months ago, in part because LWN.net seems to be the
only publication providing significant coverage of the Python Language
Summits.

------
overgard
I'm surprised the article left out mention of PyPy, which is pretty comparable
to something like V8

[http://speed.pypy.org/](http://speed.pypy.org/)

~~~
fijal
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.

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

~~~
acqq
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" Python, the fork would still be more
popular if it would be compatible enough. And there are the technical aspects:
it's not enough to make Python interpreter alone faster, whoever would take
that challenge would have to adapt various important external libraries to be
really accepted. Which is AFAIK also doable.

1)
[https://en.wikipedia.org/wiki/Lars_Bak_(computer_programmer)](https://en.wikipedia.org/wiki/Lars_Bak_\(computer_programmer\))

~~~
fijal
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_.

~~~
olskool
> unwillingness to drop the C API

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

~~~
eesmith
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.

------
fwdpropaganda
I know some of the words in that article.

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

~~~
eesmith
> "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.

Otherwise, when should people complain when speaker is disparaging most of the
people in the audience, even if accidentally?

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

