29 ms·
Faster CPython 3.12 Plan
- judge2020 4y agoIs this from an official Python Foundation group? Weird that it's not under the main `python` github org.
- __s 4y agoPython core developers are behind it at least
- rovr138 4y ago> Guido van Rossum edited this page yesterday · 13 revisions Gotta admit. That sounds pretty official
- 5d8767c68926 4y agoTo be that guy... Didn't Guido officially step down as BDFL?
- oblvious-earth 4y agoYes, he then retired, came out of retirement to work at Microsoft with a remit to work on whatever he wants, and decided the project he wanted to work on was make CPython faster.
- kzrdude 4y agoWhat's the title of the budget for employing him? General brain trust? I'm genuinely amused
- oblvious-earth 4y agoThe title is "Distinguished Engineer". I have no idea of the pay but based on my research of salaries for getting a job this year I would wildly speculate high 6 digits to low 7 digits.
- deleted 4y ago[deleted]
- wodenokoto 4y agoNo. He could be improving Python on his own time.
- LVB 4y agoSome background on the project: https://github.com/faster-cpython/ideas/blob/main/FasterCPythonDark.pdf https://github.com/faster-cpython/ideas/blob/main/FasterCPyt...
- sanxiyn 4y agoNot exactly. I would describe this to be from Microsoft faction of Python Software Foundation. So yes, some members of Python Software Foundation (mainly Microsoft employees) are behind this, but not all members are.
- wrycoder 4y agoWhile the Cpython core developers are Fellows of the PSF, the PSF does not provide technical direction. That is not its purpose.
- crazytalk 4y agoLooking forward to runnable code this time. Most of us are old enough by now to remember many project plans just like this one. Fool me once..
- nedbat 4y agoHave you followed the 3.11 performance improvements by the same group? It's ~25% faster than 3.10.
- est 4y agoHow does it compare to peak python2.x performance?
- mixmastamyk 4y agoAlready passed it with the 3.6 dict improvements iirc.
- NavinF 4y agopython2.x performance was surpassed long ago. I don't think anyone bothers to benchmark it anymore.
- jaimex2 4y agofaster at what?! That's a pretty generic statement and likely true only in a very specific frame.
- arcanemachiner 4y agohttps://www.phoronix.com/review/python-311-benchmarks/4 https://www.phoronix.com/review/python-311-benchmarks/4
- sanxiyn 4y ago25% number is from pyperformance benchmark suite, which you can replicate. Whether pyperformance is representative benchmark suite is another question. https://github.com/python/pyperformance https://github.com/python/pyperformance
- simonw 4y agohttps://github.com/faster-cpython/ideas/wiki/Python-3.12-Goals https://github.com/faster-cpython/ideas/wiki/Python-3.12-Goa... is interesting too. > Python currently has a single global interpreter lock per process, which prevents multi-threaded parallelism. This work, described in PEP 684, is to make all global state thread safe and move to a global interpreter lock (GIL) per sub-interpreter. Additionally, PEP 554 will make it possible to create subinterpreters from Python (currently a C API-only feature), opening up true multi-threaded parallelism. Very basic question: in a world where a Python program can spin up multiple subinterpreters, each of which can then execute on a separate CPU core (since they don't share a GIL), what will the best mechanisms be for passing data between those subinterpreters?
- theandrewbailey 4y ago> There are a number of valid solutions, several of which may be appropriate to support in Python. This proposal provides a single basic solution: “channels”. Ultimately, any other solution will look similar to the proposed one, which will set the precedent. Note that the implementation of Interpreter.run() will be done in a way that allows for multiple solutions to coexist, but doing so is not technically a part of the proposal here. > Regarding the proposed solution, “channels”, it is a basic, opt-in data sharing mechanism that draws inspiration from pipes, queues, and CSP’s channels. > As simply described earlier by the API summary, channels have two operations: send and receive. A key characteristic of those operations is that channels transmit data derived from Python objects rather than the objects themselves. When objects are sent, their data is extracted. When the “object” is received in the other interpreter, the data is converted back into an object owned by that interpreter. https://peps.python.org/pep-0554/#shared-data https://peps.python.org/pep-0554/#shared-data
- simonw 4y ago> Along those same lines, we will initially restrict the types that may be passed through channels to the following: > * None > * bytes > * str > * int > * channels > Limiting the initial shareable types is a practical matter, reducing the potential complexity of the initial implementation. That's a really interesting detail - presumably channels can be passed so you can do callbacks ("reply on this other channel"). I wonder why floats aren't on that list? I know they're more complex than ints, but I would expect they would still end up with a relatively simple binary representation.
- theandrewbailey 4y ago> Expose multiple interpreters to Python code > Implement PEP 554 > PEP 554 - Multiple Interpreters in the Stdlib That's going to be fun. Why fight the GIL when multithreading, when you can just get around it with more interpreters?
- isthisthingon99 4y agoIf all global state is made thread safe and, then whether threads are subinterpreters or a single interpreter is conceptually irrelevant and probably easier to implement.
- kjeetgill 4y agoIt really really depends on what you mean by global state here. If you mean the global state within the interpreter that's one thing. Preserving the global state of your application is another. But a weird "global state" (really more a global property) is the semantics between concurrent pieces of code and the expectations about things like setting variables, possibly interleavings etc. The nice part of different interpreters isn't just getting around the gil, and maintaining similar isolation, but it's almost like a Terms and Services agreement: I opened this can of worms and it's my responsibility to learn what the consequences are.
- forrestthewoods 4y ago> conceptually irrelevant and probably easier to implement. Well, it depends on how it’s implemented. If “made thread safe” means constantly grabbing locks around large blocks of data then the end result is concurrency (hopefully!) but not parallelism. Meaning you might only have one thread active at a time in practice. Wrapping the universe in a mutex is thread safe. But it’s not a good solution.
- isthisthingon99 4y agoI presume they know what they are doing and won't be doing a big world mutex :-)
- 4y ago
- School-Cotton 4y agoDoes anyone know what came of Sam Gross’s proof of concept that removed the GIL entirely? Is that proposal effectively dead?
- js2 4y agoLooks like it's still active to me: https://github.com/colesbury/nogil/ https://github.com/colesbury/nogil/
- freediver 4y agoTested it this morning and it is actually slower in a combined benchmark than 3.11.
- dwrodri 4y agoI think it's been decided that such a change was so large that it would require a major version change in Python. However, I think that was unauthoritative hearsay probably in another comment thread here on HN. But it stands to reason that removing the GIL will almost certainly change Python's memory model in some ways that could break code in ways that warrant a major version bump.
- KronisLV 4y ago> I think it's been decided that such a change was so large that it would require a major version change in Python. Hah, I wonder what else Python 4 could have in it. The Python 2 to 3 migration was hard enough and there were certain challenges along the way (mostly package availability and syntax changes, though the same is happening with new Vue versions) but it seems that in regards to most metrics Python 3 was indeed an improvement, apart from the startup time.
- rat9988 4y agoAn improvement that was not worth the cost. I guess many people aren't looking forward python 4.
- jupp0r 4y ago> Per-interpreter isolation for extension modules This will break many modules. Basically any that use static variables, which is done pretty much everywhere.
- jensus 4y agoIf it's static would it not get it's own allocation within each of the isolated interpreters?
- int_19h 4y agoIt's all a single process, and native modules are just shared libraries, so how would it allocate multiple instances for different interpreters?
- unnah 4y agoDoes anyone know of a way to load multiple instances of a DLL in the same process on Linux? A few months ago I was googling for a solution and didn't find anything ready-made. I guess the dynamic linker wants to have a unique address for each symbol, but in principle you should be able to load another DLL instance, initialize it and call its functions indirectly by using function pointers.
- jupp0r 4y agoStatic modules are loaded as shared libraries/dlls. The way operating systems implement this is that each library is loaded once per process and that statically allocated memory is mapped into the virtual address space of the process. You can't load one so/dll multiple times in some sort of container, so each module would have to implement this isolation inside their module, probably through some sort of API that the python runtime offers to the module. It's not rocket science but it will definitely break existing code where it's common practice to use dll lifetime hooks as initialization code that allocated some global state that's conveniently shared throughout the module.
- MikeYasnev007 4y agoI will review this tech during this week also as jq tools
- MikeYasnev007 4y agoPerhaps it is also good to build Artemis project on hn infra. Articles and discussions. I will create mirror on habr
- qeternity 4y agoIt’s a bit frustrating to see the first item related to parallelism and the GIL. Anybody doing parallel compute in Python has long since worked around these issues. IMHO Python needs better single threaded performance first, and then once all the juice has been squeezed from that lemon, we can sit down and get serious about improving multi threaded ergonomics.
- staticassertion 4y agoI don't really use Python if I can help it, but I'm still really glad to see people working on this. Whether I like it or not Python will probably always be some part of my job and I really appreciate that there's finally some focus on it getting faster that isn't just "write that part in C".
- jokoon 4y agoI wonder if python could possibly be as fast as js if enough money was spent on it.
- _joel 4y agoIt's not a case of money imho, it's a case of it's a juggernaut of a userbase and ecosystem that moves very slowly and implementing improvements to execution times (generally) are intremental changes, not paradigm shifts as they make backwards compatability a nightmare/impossible. I mean 2.x is still in the wild and some companies provide support for it, still!
- mindwok 4y agoI think the other issue if we compare it to JS is the unfortunate reliance on C that python has. When Chrome came around, JavaScript was already standardised and there were many competing implementations which had to conform to ECMAScript and give users a relatively consistent experience. So when Google made V8 they could kind of go crazy with optimisations as long as they conformed to the spec. Python on the other hand has one real implementation, and the ecosystem has become extremely intertwined with that implementation. Implementing a new Python interpreter is great, but it rarely gains traction because most of the ecosystem is so reliant on CPython specific modules that don’t work in the new interpreter so they never really get off the ground.
- IshKebab 4y agoUnlikely. Python has lots of features that were added without any thought to how to make them run fast - it simply wasn't a goal. As a result Python includes a ton of dynamic features that make it really hard to optimise.
- ahrzb 4y agoI don’t think so, there are some design choices that make the two quite different. This „dictionaries all the way down“ approach has a cost.
- miohtama 4y agoThis is possible, but it would need some backwards incompatible in the object model. We still are likely to see Python 4 on one day. People are still remembering the pain Python 3 transition caused.
- sylware 4y agoI would seriously consider a risc-v assembly port of a python interpreter. Removing fanatic compiler abuse is always a good thing. That said, I saw some assembler macro abuse (some assemblers out there have extremely powerful and complex macro pre-processors), then the hard part would be not to abuse the macro pre-processor of the assembler. I know it is not to make python actually "faster", but to have a python implementation which does not require those grotesquely and absurdely massive compilers, then the SDK stack would be way more reasonable from a technical cost stand point.
- deleted 4y ago[deleted]
- Whitespace 4y agoI'm glad to see this as an outline, which is how I structure most of my project work. It can be hard for others to follow, but it's very concise and scannable (just read the first indentation level for the top-level idea). To paraphrase Adam Savage from his excellent book, Every Tool's a Hammer, lists [of lists] are very powerful way to tame the inherit complexity of any project worth doing.
- d0mine 4y agoYou might like creating outline using Org mode (the ultimate hammer) https://www.youtube.com/watch?v=VcgjTEa0kU4&t=344 https://www.youtube.com/watch?v=VcgjTEa0kU4&t=344
- robertlagrant 4y agoHow will this affect things if I have an instance of the built in SQLite? Will it be accessible by multiple GILs at once?
- remram 4y agoYes, just like you can already access it from multiple threads in the same interpreter right now.
- RantyDave 4y agoSo, is the GIL released when the thread goes to SQLite? Is the behaviour dependent on how the interfacing between Python and C is written?
- remram 4y agoYes, it is released [1]. This allows you to access it from multiple thread in the same interpreter though, so I still don't understand robertlagrant's question. [1]: https://github.com/python/cpython/blob/4b81139aac3fa11779f6eedb6e621bde29e64b30/Modules/_sqlite/cursor.c#L518-L520 https://github.com/python/cpython/blob/4b81139aac3fa11779f6e...
- robertlagrant 4y ago> Yes, just like you can already access it from multiple threads in the same interpreter right now. Yes, but doesn't the GIL currently serialise things?
- remram 4y agoThe GIL serializes all the things you can do in Python... I am not sure I understand the question to be honest.
- robertlagrant 4y agoWith the new multi-GIL I wonder how different concurrent GILs will work against the same sqlite database.
- lsofzz 4y agoA "faster" CPython is a decade plus minus four years old story ;_; I'll check back in a decade.
- melonrusk 4y agoAre there any plans to remove threading from python ? A year or two ago I read up on the various efforts to make a fast, more parallel CPython, and one of the core underlying problems seemed to be the use of machine threads, resulting in a very high locking load as the large (potentially unlimited) number of threads attempted to defend against each other. Letting an operating system run random fragments of your code at random times is very much a self-inflicted wound, so I was wondering if the python community has any plans to not do that any more ?
- miohtama 4y agoThreaded IO code on Python is fine if you are IO limited, as opposite to CPU limited. Most web workloads are like this as they wait database.