News: 1620921910

  ARM Give a man a fire and he's warm for a day, but set fire to him and he's warm for the rest of his life (Terry Pratchett, Jingo)

Guido van Rossum aiming to make CPython 2x faster in 3.11

(2021/05/13)


Language Summit Python creator Guido van Rossum this week told attendees at the Language Summit that he hopes to double performance in version 3.11.

The programming language is relatively slow in its default CPython implementation, though there are many [1]ways to make it faster including performance-oriented alternatives like PyPy. Historically Van Rossum had seemed unconcerned about Python performance, favouring the simplicity of a compiler that is less well optimized.

Slides from the summit [2]now posted [PDF] suggest a change of heart. "I got bored sitting at home while retired," he said. "I applied at Microsoft and got hired. I was given freedom to pick a project. I chose to go back to my roots. This is Microsoft's way of giving back to Python."

[3]

[4]

[5]

The project is a "small team funded by Microsoft," to include Python Core developer and Microsoft Senior Software Engineer Eric Snow, and Mark Shannon, research engineer at [6]Semmle , which develops produces for code security analysis. Semmle has been part of [7]GitHub since September 2019 , so this is an all-Microsoft team, though Van Rossum noted it "might grow".

The project has a [8]GitHub repository which includes a fork of CPython as well as an issue tracker for ideas and tools for analysing performance. According to Van Rossum, there will be "no long-lived forks/branches, no surprise 6,000 line pull requests," and everything will be open source.

Shannon has worked on Python performance for some time, with previous projects HotPy and [9]HotPy (2) for a just-in-time compiler for CPython.

[10]

He has his own [11]Faster CPython repository where he wrote that "we want to speed up CPython by a factor of 5 over the next four releases."

He noted though that some platforms, such as Apple's iOS, do not allow "runtime code generation," but believes that even in these cases a doubling of speed should be possible.

Although Shannon envisages a JIT compiler eventually, this would not come until Python 3.12 in his plan. The changes for Python 3.11 would be based on "lots of tweaks" such as better memory layout, improved performance for small integers, faster calls and returns, and zero overhead exception handling.

[12]

There are number of constraints, as Van Rossum noted in his talk, including not breaking stable ABI (Application Binary Interface) compatibility, keeping code compatible, and not causing slowdowns in edge cases. He said that many things can be safely changed though, including the Python bytecode, stack frame layout, compiler and interpreter. The stack frame layout describes how the data which defines a function is positioned in memory.

The notes by Van Rossum seem to match well with Shannon's existing ideas. "There's machine code generation in our future," he said, and like Shannon, refers to 5x speedup as a long-term goal, even though "we'll have to be creative."

Python 3.10, currently in beta, is scheduled for release in October this year. The release schedule is roughly annual, so we might expect 3.11 in October 2022. ®

Get our [13]Tech Resources



[1] https://www.theregister.com/2021/05/06/the_quest_for_faster_python/

[2] https://github.com/faster-cpython/ideas/blob/main/FasterCPythonDark.pdf

[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YJ2hejg2URIFyC2r--C-cQAAAIc&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0

[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YJ2hejg2URIFyC2r--C-cQAAAIc&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0

[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YJ2hejg2URIFyC2r--C-cQAAAIc&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0

[6] https://www.theregister.com/2020/12/01/githubs_journey_towards_microservices/

[7] https://www.theregister.com/2019/09/18/github_code_analysis_biz_semmle/

[8] https://github.com/faster-cpython

[9] https://sites.google.com/site/makingcpythonfast/

[10] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YJ2hejg2URIFyC2r--C-cQAAAIc&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0

[11] https://github.com/markshannon/faster-cpython

[12] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YJ2hejg2URIFyC2r--C-cQAAAIc&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0

[13] https://whitepapers.theregister.com/

The proof of the pudding will be in the eating.

thames

From reading the references, it appears that they hope to get most of the performance increase from using an "adaptive specializing interpreter". Experiments with this have given a 25% to 50% increase in performance.

The real question of course will be what sort of applications will benefit from this. Most comparative language micro-benchmarks you see on the Internet were written to show off specific optimizations of particular compilers. If your code deviates too much from the micro-benchmark the performance vanishes.

One of the previous attempts at performance optimization in Python was called "Unladen Swallow" and involved adding an LLVM based JIT compiler to Python. It did fantastic on the common multi-language micro-benchmarks that many people like to use. However, tests in actual applications found that it made real world code slower .

The Unladen Swallow team then constructed a set of benchmarks based on a selection of large blocks of code used in a broad selection of common applications. Based on the results of this they decided the LLVM based JIT compiler was not a promising approach after all, and that standard JIT compilers were not a magical solution.

The only thing that survived from the Unladen Swallow project was the benchmark, which subsequent projects such as Pypy. The latter is another Python implementation, which uses a "specializing JIT compiler" and which does show real performance increases but sacrifices compatibility with C extensions (which is why it has seen limited use).

The way these sorts of projects tend to go is that we won't really know whether the ideas being pursued will actually work until it's done and tested on real world code. Overall though, it looks very interesting.

Re: The proof of the pudding will be in the eating.

druck

This is very welcome and will more than reverse the small loss of performance when migrating from Python 2.

I got bored sitting at home while retired ... I chose to go back to my roots

ST

Please don't. You've done enough damage already.

Retirement at Microsoft is good. Really good.

Re: I got bored sitting at home while retired ... I chose to go back to my roots

Fruit and Nutcase

Who knows, a newly divorced Bill Gates, with only half his billions to give away may find he is bored now that he Melinda won't be getting him to help with the housework either, decides to get back to his roots and start coding at Microsoft

Re: I got bored sitting at home while retired ... I chose to go back to my roots

ZanzibarRastapopulous

Did Bill ever do any actual coding?

static buildup