Re: [Python-Dev] Can I make marshal.dumps() slower but stabler?

2018-07-11 Thread Serhiy Storchaka
12.07.18 08:43, INADA Naoki пише: I'm working on making pyc stable, via stablizing marshal.dumps() https://bugs.python.org/issue34093 This is not enough for making pyc stable. The order in frozesets still is arbitrary. Sadly, it makes marshal.dumps() 40% slower. Luckily, this overhead is sm

[Python-Dev] Can I make marshal.dumps() slower but stabler?

2018-07-11 Thread INADA Naoki
I'm working on making pyc stable, via stablizing marshal.dumps() https://bugs.python.org/issue34093 Sadly, it makes marshal.dumps() 40% slower. Luckily, this overhead is small (only 4%) for dumps(compile(source)) case. So my question is: May I remove unstable but faster code? Or should I make t

Re: [Python-Dev] Micro-benchmarks for PEP 580

2018-07-11 Thread INADA Naoki
On Thu, Jul 12, 2018 at 4:54 AM Jeroen Demeyer wrote: > > On 2018-07-11 10:50, Victor Stinner wrote: > > As you wrote, the > > cost of function costs is unlikely the bottleneck of application. > > With that idea, METH_FASTCALL is not needed either. I still find it very > strange that nobody seems

[Python-Dev] Accepting PEP 572, Assignment Expressions

2018-07-11 Thread Guido van Rossum
As anticippated, after a final round of feedback I am hereby accepting PEP 572, Assignment Expressions: https://www.python.org/dev/peps/pep-0572/ Thanks to everyone who participated in the discussion or sent a PR. Below is a list of changes since the last post (https://mail.python.org/ pipermail/

Re: [Python-Dev] Micro-benchmarks for PEP 580

2018-07-11 Thread Jeroen Demeyer
On 2018-07-11 10:50, Victor Stinner wrote: As you wrote, the cost of function costs is unlikely the bottleneck of application. With that idea, METH_FASTCALL is not needed either. I still find it very strange that nobody seems to question all the crazy existing optimizations for function calls

Re: [Python-Dev] Micro-benchmarks for PEP 580

2018-07-11 Thread Jeroen Demeyer
On 2018-07-11 10:27, Antoine Pitrou wrote: I agree PEP 580 is extremely complicated and it's not obvious what the maintenance burden will be in the long term. But the status quo is also very complicated! If somebody would write a PEP describing the existing implementation of builtin_function_o

Re: [Python-Dev] Micro-benchmarks for PEP 580

2018-07-11 Thread Jeroen Demeyer
On 2018-07-11 00:48, Victor Stinner wrote: About your benchmark results: "FASTCALL unbound method(obj, 1, two=2): Mean +- std dev: 42.6 ns +- 29.6 ns" That's a very big standard deviation :-( Yes, I know. My CPU was overheating and was slowed down. But that seemed to have happened for a smal

Re: [Python-Dev] A more flexible task creation

2018-07-11 Thread Michel Desmoulin
> To be honest, I see "async with" being abused everywhere in asyncio, > lately.  I like to have objects with start() and stop() methods, but > everywhere I see async context managers.> > Fine, add nursery or whatever, but please also have a simple start() / > stop() public API. > > "async with"

Re: [Python-Dev] Micro-benchmarks for PEP 580

2018-07-11 Thread Nick Coghlan
On 11 July 2018 at 18:50, Victor Stinner wrote: > I'm skeptical about "50% gain": I want to see a working implementation > and reproduce benchmarks myself to believe that :-) As you wrote, the > cost of function costs is unlikely the bottleneck of application. > > Sorry, I didn't read all these PE

Re: [Python-Dev] Micro-benchmarks for PEP 580

2018-07-11 Thread Victor Stinner
2018-07-11 2:12 GMT+02:00 INADA Naoki : > If my idea has 50% gain and current PEP 580 has only 5% gain, > why we should accept PEP 580? > But no one know real gain, because there are no realistic application > which bottleneck is calling overhead. I'm skeptical about "50% gain": I want to see a wo

Re: [Python-Dev] Micro-benchmarks for function calls (PEP 576/579/580)

2018-07-11 Thread Victor Stinner
2018-07-11 9:19 GMT+02:00 Andrea Griffini : > May be is something obvious but I find myself forgetting often about > the fact that most modern CPUs can change speed (and energy consumption) > depending on a moving average of CPU load. > > If you don't disable this "green" feature and the benchmarks

Re: [Python-Dev] Micro-benchmarks for PEP 580

2018-07-11 Thread Antoine Pitrou
On Wed, 11 Jul 2018 09:12:11 +0900 INADA Naoki wrote: > > Without example application, I can't consider PEP 580 seriously. > Microbenchemarks doesn't attract me. > And PEP 576 seems much simpler and straightforward way to expose > FASTCALL. I agree PEP 580 is extremely complicated and it's not o

Re: [Python-Dev] why is not 64-bit installer the default download link for Windows?

2018-07-11 Thread Paul Moore
On 11 July 2018 at 06:39, Steven D'Aprano wrote: > On Wed, Jul 11, 2018 at 05:14:34AM +0300, Ivan Pozdeev via Python-Dev wrote: >> On 11.07.2018 1:41, Victor Stinner wrote: >> >2018-07-09 18:01 GMT+02:00 Steve Dower : >> >>The difficulty is that they *definitely* can use the 32-bit version, and >>

Re: [Python-Dev] Micro-benchmarks for PEP 580

2018-07-11 Thread INADA Naoki
First of all, please don't be so defensive. I just say I need example target application. I don't against to PEP 580. Actually speaking, I lean to PEP 580 than PEP 576, although I wonder if some part of PEP 580 can be simplified or postponed. But PEP 580 is very complicated. I need enough evid

Re: [Python-Dev] Micro-benchmarks for function calls (PEP 576/579/580)

2018-07-11 Thread Andrea Griffini
May be is something obvious but I find myself forgetting often about the fact that most modern CPUs can change speed (and energy consumption) depending on a moving average of CPU load. If you don't disable this "green" feature and the benchmarks are quick then the result can have huge variations d