Re: [Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

2018-02-20 Thread Nick Coghlan
On 21 February 2018 at 08:40, Guido van Rossum wrote: > On Tue, Feb 20, 2018 at 12:54 PM, Barnstone Worthy > wrote: > > I'm pretty sure that's an alias for Barry Warsaw. :-) Different Barry :) I've expanded the existing issue at

Re: [Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

2018-02-20 Thread Guido van Rossum
On Tue, Feb 20, 2018 at 12:54 PM, Barnstone Worthy wrote: I'm pretty sure that's an alias for Barry Warsaw. :-) -- --Guido van Rossum (python.org/~guido) ___ Python-ideas mailing list Python-ideas@python.org

Re: [Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

2018-02-20 Thread Barry
> On 20 Feb 2018, at 13:12, Nick Coghlan wrote: > >> On 20 February 2018 at 16:17, Antoine Pitrou wrote: >> On Mon, 19 Feb 2018 20:15:27 +0100 >> Stefan Behnel wrote: >>> Nick Coghlan schrieb am 02.02.2018 um 06:47: to make

Re: [Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

2018-02-20 Thread Nick Coghlan
On 20 February 2018 at 16:17, Antoine Pitrou wrote: > On Mon, 19 Feb 2018 20:15:27 +0100 > Stefan Behnel wrote: >> Nick Coghlan schrieb am 02.02.2018 um 06:47: >> > to make the various extension module authoring tools >> > easier to discover, rather than

Re: [Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

2018-02-19 Thread Antoine Pitrou
On Mon, 19 Feb 2018 20:15:27 +0100 Stefan Behnel wrote: > Nick Coghlan schrieb am 02.02.2018 um 06:47: > > to make the various extension module authoring tools > > easier to discover, rather than having folks assuming that handcrafted > > calls directly into the CPython C API

Re: [Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

2018-02-19 Thread Stefan Behnel
Nick Coghlan schrieb am 02.02.2018 um 06:47: > to make the various extension module authoring tools > easier to discover, rather than having folks assuming that handcrafted > calls directly into the CPython C API is their only option. Or even a competitive option. Tools like Cython or pybind11 go

Re: [Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

2018-02-01 Thread Nick Coghlan
On 2 February 2018 at 06:15, Barry Scott wrote: > > > On 30 Jan 2018, at 05:45, Nick Coghlan wrote: > > I'll also note that one of the things we (and others) *have* been > putting quite a bit of time into is the question of "Why do people > avoid using

Re: [Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

2018-02-01 Thread Barry Scott
> On 30 Jan 2018, at 05:45, Nick Coghlan wrote: > > I'll also note that one of the things we (and others) *have* been > putting quite a bit of time into is the question of "Why do people > avoid using extension modules for code acceleration?". I think that is simple. Those

Re: [Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

2018-02-01 Thread Pau Freixes
I'm not sure I understand Pau's question but I can assure that my optimizations were fully backwards compatible and preserved all of Python attribute lookup semantics. And they made some macrobenchmarks up to 10% faster. Unfortunately I failed at merging them in 3.7. Will do that for 3.8. I

Re: [Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

2018-02-01 Thread Yury Selivanov
On Thu, Feb 1, 2018 at 12:55 PM, Brett Cannon wrote: > > > On Thu, 1 Feb 2018 at 07:34 Pau Freixes wrote: [..] >> 2) Regarding the Yuris proposal to cache bultin functions, why this >> strategy cant be used for objects and their attributes within the

Re: [Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

2018-02-01 Thread Brett Cannon
On Thu, 1 Feb 2018 at 07:34 Pau Freixes wrote: > Maybe it is happening but not in the way that you would expect > > https://mail.python.org/pipermail/python-dev/2018-January/152029.html > > As one of the people who works at Microsoft and has Steve as a teammate I'm well aware

Re: [Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

2018-02-01 Thread Pau Freixes
Maybe it is happening but not in the way that you would expect https://mail.python.org/pipermail/python-dev/2018-January/152029.html Anyway, do we conclude, or at least a significant part, that is something desiderable but some constraints do not allow to work on that? Also, more technically

Re: [Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

2018-01-30 Thread Chris Barker - NOAA Federal
> > It's easier to make a good language fast than it is to make a fast language > good. It's easier to hack a compiler or an interpreter to run slow code > faster than it is to hack the human brain to understand confusing code more > easily. So I think the smart move is to take the languages

Re: [Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

2018-01-30 Thread Barry Warsaw
Antoine Pitrou wrote: > Moore's Law doesn't really apply to semiconductors anymore either, and > transistor size scaling is increasingly looking like it's reaching its > end. You forget about the quantum computing AI blockchain in the cloud. OTOH, I still haven't perfected my clone army yet.

Re: [Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

2018-01-30 Thread Antoine Pitrou
On Mon, 29 Jan 2018 23:24:43 -0500 Barry Warsaw wrote: > > This is often undervalued, but shouldn't be! Moore's Law doesn't apply > to humans, and you can't effectively or cost efficiently scale up by > throwing more bodies at a project. Moore's Law doesn't really apply to

Re: [Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

2018-01-30 Thread Brendan Barnwell
On 2018-01-29 20:24, Barry Warsaw wrote: But there's something else that's very important to consider, which rarely comes up in these discussions, and that's the developer's productivity and programming experience. One of the things that makes Python so popular and effective I think, is that it

Re: [Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

2018-01-30 Thread Antoine Pitrou
On Tue, 30 Jan 2018 09:14:06 -0800 Chris Barker wrote: > On Sat, Jan 27, 2018 at 10:14 PM, Nick Coghlan wrote: > > > More broadly, the current lack of perceived commercial incentives for > > large corporations to invest millions in offering a faster

Re: [Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

2018-01-30 Thread Chris Barker
On Mon, Jan 29, 2018 at 9:45 PM, Nick Coghlan wrote: > > I'll also note that one of the things we (and others) *have* been > putting quite a bit of time into is the question of "Why do people > avoid using extension modules for code acceleration?". > well, the scientific

Re: [Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

2018-01-29 Thread Nick Coghlan
On 30 January 2018 at 14:24, Barry Warsaw wrote: > This is often undervalued, but shouldn't be! Moore's Law doesn't apply > to humans, and you can't effectively or cost efficiently scale up by > throwing more bodies at a project. Python is one of the best languages > (and

Re: [Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

2018-01-29 Thread Barry Warsaw
Just to add another perspective, I find many "performance" problems in the real world can often be attributed to factors other than the raw speed of the CPython interpreter. Yes, I'd love it if the interpreter were faster, but in my experience a lot of other things dominate. At least they do

Re: [Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

2018-01-29 Thread Brett Cannon
On Sat, Jan 27, 2018, 23:36 Pau Freixes, wrote: > > At a technical level, the biggest problems relate to the way we > > manipulate frame objects at runtime, including the fact that we expose > > those frames programmatically for the benefit of debuggers and other > > tools. >

Re: [Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

2018-01-28 Thread Antoine Pitrou
On Sat, 27 Jan 2018 22:18:08 +0100 Pau Freixes wrote: > > Correct me if I'm wrong, but most of you argue that the proper Zen of > Python - can we say it mutability [1]? as Victor pointed out - that > allow the user have the freedom to mutate objects in runtime goes in > the

Re: [Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

2018-01-27 Thread Pau Freixes
> At a technical level, the biggest problems relate to the way we > manipulate frame objects at runtime, including the fact that we expose > those frames programmatically for the benefit of debuggers and other > tools. Shoudnt be something that could be tackled with the introduction of a kind of

Re: [Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

2018-01-27 Thread Nick Coghlan
On 28 January 2018 at 07:18, Pau Freixes wrote: > Regarding the cost of calling a function, that I can guess is not > related with the previous stuff, what is an impediment right now to > make it faster ? At a technical level, the biggest problems relate to the way we

Re: [Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

2018-01-27 Thread David Mertz
> > def filter(rule, whatever): > if rule.x in whatever.x: > return True > > rules = get_rules() > whatevers = get_whatevers() > for rule in rules: > for whatever in whatevers: > if filter(rule, whatever): > cnt = cnt + 1 > > return cnt > This code seems almost

Re: [Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

2018-01-27 Thread Pau Freixes
Hi, Thanks to all of you for your responses, the points of view and the information that you shared to back up your rationales, I had some time to visit few of them but sure I will try to suit the proper time to review all of them. It's hard to try to keep the discussion organized responding at

Re: [Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

2018-01-27 Thread Stephan Houben
Hi all, I would like to remark that, in my opinion, the question of CPython's performance cannot be decoupled from the extremely wide selection of packages which provide optimized code for almost any imaginable task. For example: Javascript may be faster than (C)Python on simple benchmarks, but

Re: [Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

2018-01-26 Thread Cameron Simpson
On 26Jan2018 20:59, Soni L. wrote: On 2018-01-26 08:18 PM, Chris Barker wrote: If there are robust and simple optimizations that can be added to CPython, great, but: This mail is the consequence of a true story, a story where CPython got defeated by Javascript,

Re: [Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

2018-01-26 Thread Chris Angelico
On Sat, Jan 27, 2018 at 10:07 AM, Steven D'Aprano wrote: > On Sat, Jan 27, 2018 at 09:12:29AM +1100, Chris Angelico wrote: > >> Are you sure it's the language's fault? Failing to use a better data >> type simply because some other language doesn't have it is a great way >> to

Re: [Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

2018-01-26 Thread Steven D'Aprano
On Fri, Jan 26, 2018 at 02:18:53PM -0800, Chris Barker wrote: [...] > sure, but I would argue that you do need to write code in a clean style > appropriate for the language at hand. Indeed. If you write Java-esque code in Python with lots of deep chains obj.attr.spam.eggs.cheese.foo.bar.baz

Re: [Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

2018-01-26 Thread Victor Stinner
Hi, Well, I wrote https://faster-cpython.readthedocs.io/ website to answer to such question. See for example https://faster-cpython.readthedocs.io/mutable.html "Everything in Python is mutable". Victor 2018-01-26 22:35 GMT+01:00 Pau Freixes : > Hi, > > This mail is the

Re: [Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

2018-01-26 Thread Steven D'Aprano
On Sat, Jan 27, 2018 at 09:12:29AM +1100, Chris Angelico wrote: > Are you sure it's the language's fault? Failing to use a better data > type simply because some other language doesn't have it is a great way > to make a test that's "fair" in the same way that Balance and > Armageddon are "fair"

Re: [Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

2018-01-26 Thread Soni L.
On 2018-01-26 08:18 PM, Chris Barker wrote: If there are robust and simple optimizations that can be added to CPython, great, but: This mail is the consequence of a true story, a story where CPython got defeated by Javascript, Java, C# and Go. at least those last three are

Re: [Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

2018-01-26 Thread Chris Angelico
On Sat, Jan 27, 2018 at 8:35 AM, Pau Freixes wrote: > def filter(rule, whatever): > if rule.x in whatever.x: > return True > > rules = get_rules() > whatevers = get_whatevers() > for rule in rules: > for whatever in whatevers: > if filter(rule,

Re: [Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

2018-01-26 Thread Edward Minnix
There are several reasons for the issues you are mentioning. 1. Attribute look up is much more complicated than you would think.  (If you have the time, watch https://www.youtube.com/watch?v=kZtC_4Ecq1Y that will explain things better than I can)  The series of operations that happen with every

[Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

2018-01-26 Thread Pau Freixes
Hi, This mail is the consequence of a true story, a story where CPython got defeated by Javascript, Java, C# and Go. One of the teams of the company where Im working had a kind of benchmark to compare the different languages on top of their respective "official" web servers such as Node.js,