Re: [Python-Dev] Speeding up CPython 5-10%

Also, modern compiler technology tends to use "infinite register" machines for the intermediate representation, then uses register coloring to assign the actual registers (and generate spill code if needed). I've seen work on inter-function optimization for avoiding some register loads and stores

Re: [Python-Dev] Opcode cache in ceval loop

On 2016-02-02 12:41 PM, Serhiy Storchaka wrote: On 01.02.16 21:10, Yury Selivanov wrote: To measure the max/average memory impact, I tuned my code to optimize *every* code object on *first* run. Then I ran the entire Python test suite. Python test suite + standard library both contain

Re: [Python-Dev] Speeding up CPython 5-10%

On Tue, 2 Feb 2016 at 01:29 Victor Stinner wrote: > Hi, > > I'm back for the FOSDEM event at Bruxelles, it was really cool. I gave > talk about FAT Python and I got good feedback. But friends told me > that people now have expectations on FAT Python. It looks like

Re: [Python-Dev] Opcode cache in ceval loop

Hi Victor, On 2016-02-02 4:33 AM, Victor Stinner wrote: Hi, Maybe it's worth to write a PEP to summarize all your changes to optimize CPython? It would avoid to have to follow different threads on the mailing lists, different issues on the bug tracker, with external links to GitHub gists, etc.

Re: [Python-Dev] Opcode cache in ceval loop

On 02.02.2016 20:41, Yury Selivanov wrote: Hi Victor, On 2016-02-02 4:33 AM, Victor Stinner wrote: Hi, Maybe it's worth to write a PEP to summarize all your changes to optimize CPython? It would avoid to have to follow different threads on the mailing lists, different issues on the bug

Re: [Python-Dev] Opcode cache in ceval loop

On 2016-02-02 1:45 PM, Serhiy Storchaka wrote: On 02.02.16 19:45, Yury Selivanov wrote: On 2016-02-02 12:41 PM, Serhiy Storchaka wrote: On 01.02.16 21:10, Yury Selivanov wrote: To measure the max/average memory impact, I tuned my code to optimize *every* code object on *first* run. Then I

Re: [Python-Dev] Opcode cache in ceval loop

2016-02-02 20:23 GMT+01:00 Yury Selivanov : > Alright, I modified the code to optimize ALL code objects, and ran unit > tests with the above tests excluded: > > -- Max process mem (ru_maxrss) = 131858432 > -- Opcode cache number of objects = 42109 > -- Opcode cache

Re: [Python-Dev] Opcode cache in ceval loop

On 02.02.16 21:23, Yury Selivanov wrote: Alright, I modified the code to optimize ALL code objects, and ran unit tests with the above tests excluded: -- Max process mem (ru_maxrss) = 131858432 -- Opcode cache number of objects = 42109 -- Opcode cache total extra mem= 10901106 Thank

Re: [Python-Dev] Opcode cache in ceval loop

>> I can write a ceval.txt file explaining what's going on >> in ceval loop, with details on the opcode cache and other >> things. I think it's even better than a PEP, to be honest. > > > I totally agree. > Please include the notes text file. This provides an excellent summary for those of us

Re: [Python-Dev] Opcode cache in ceval loop

Yury Selivanov writes: > Not sure about that... PEPs take a LOT of time :( Informational PEPs need not take so much time, no more than you would spend on ceval.txt. I'm sure a PEP would get a lot more attention from reviewers, too. Even if you PEP the whole thing, as you say it's a (big ;-)

Re: [Python-Dev] Opcode cache in ceval loop

On 02.02.16 21:41, Yury Selivanov wrote: I can write a ceval.txt file explaining what's going on in ceval loop, with details on the opcode cache and other things. I think it's even better than a PEP, to be honest. I totally agree. ___ Python-Dev

Re: [Python-Dev] Opcode cache in ceval loop

On 02.02.16 19:45, Yury Selivanov wrote: On 2016-02-02 12:41 PM, Serhiy Storchaka wrote: On 01.02.16 21:10, Yury Selivanov wrote: To measure the max/average memory impact, I tuned my code to optimize *every* code object on *first* run. Then I ran the entire Python test suite. Python test

Re: [Python-Dev] Speeding up CPython 5-10%

On 2016-02-02 4:28 AM, Victor Stinner wrote: [..] I take a first look at your patch and sorry, Thanks for the initial code review! I'm skeptical about the design. I have to play with it a little bit more to check if there is no better design. So far I see two things you are worried

Re: [Python-Dev] [Python-checkins] cpython: merge

On 2 February 2016 at 05:21, raymond.hettinger wrote: > https://hg.python.org/cpython/rev/0731f097157b > changeset: 100142:0731f097157b > parent: 100140:c7f1acdd8be1 > user:Raymond Hettinger > date:Mon Feb 01 21:21:19 2016 -0800

Re: [Python-Dev] Speeding up CPython 5-10%

Hi, I'm back for the FOSDEM event at Bruxelles, it was really cool. I gave talk about FAT Python and I got good feedback. But friends told me that people now have expectations on FAT Python. It looks like people care of Python performance :-) FYI the slides of my talk:

Re: [Python-Dev] Opcode cache in ceval loop

Hi, Maybe it's worth to write a PEP to summarize all your changes to optimize CPython? It would avoid to have to follow different threads on the mailing lists, different issues on the bug tracker, with external links to GitHub gists, etc. Your code changes critical parts of Python: code object

Re: [Python-Dev] Speeding up CPython 5-10%

On 02.02.2016 00:27, Greg Ewing wrote: Sven R. Kunze wrote: Are there some resources on why register machines are considered faster than stack machines? If a register VM is faster, it's probably because each register instruction does the work of about 2-3 stack instructions, meaning less

Re: [Python-Dev] Opcode cache in ceval loop

On 01.02.16 21:10, Yury Selivanov wrote: To measure the max/average memory impact, I tuned my code to optimize *every* code object on *first* run. Then I ran the entire Python test suite. Python test suite + standard library both contain around 72395 code objects, which required 20Mb of memory

[Python-Dev] Python environment registration in the Windows Registry

I was throwing around some ideas with colleagues about how we detect Python installations on Windows from within Visual Studio, and it came up that there are many Python distros that install into different locations but write the same registry entries. (I knew about this, of course, but this