'Faster, Leaner' Python 3.12 Released Today with Improvements to Speed, Multiprocessing (infoworld.com) 53
Python 3.12 was released today, with improvements to speed and efficiency, reports InfoWorld. Core developers explained the improvements at this year's PyCon convention in Salt Lake City, Utah, including efforts to reduce Python's memory use, make the interpreter faster, and optimize compilation for more efficient code:
Subinterpreters is a mechanism where the Python runtime can have multiple interpreters running together inside a single process, as opposed to each interpreter being isolated in its own process (the current multiprocessing mechanism)... While subinterpreters have been available in the Python runtime for some time now, they haven't had an interface for the end user. Also, the messy state of Python's internals hasn't allowed subinterperters to be used effectively. With Python 3.12, core python developer Eric Snow and his cohort cleaned up Python's internals enough to make subinterpreters useful, and they are adding a minimal module to the Python standard library called interpreters. This gives programmers a rudimentary way to launch subinterpreters and execute code on them.
Snow's own initial experiments with subinterpreters significantly outperformed threading and multiprocessing. One example, a simple web service that performed some CPU-bound work, maxed out at 100 requests per second with threads, and 600 with multiprocessing. But with subinterpreters, it yielded 11,500 requests, and with little to no drop-off when scaled up from one client. The interpreters module has very limited functionality right now, and it lacks robust mechanisms for sharing state between subinterpreters. But Snow believes by Python 3.13 a good deal more functionality will appear, and in the interim developers are encouraged to experiment...
Python 3.11 introduced new bytecodes to the interpreter, called adaptive instructions. These instructions can be replaced automatically at runtime with versions specialized for a given Python type, a process called quickening. This saves the interpreter the step of having to look up what types the objects are, speeding up the whole process enormously. For instance, if a given addition operation regularly takes in two integers, that instruction can be replaced with one that assumes the operands are both integers... Python 3.12 has more adaptive specialization opcodes...
And starting with Python 3.12, object headers now use 96 bytes, which InfoWorld reports is "slightly less than half of what it was before."
Snow's own initial experiments with subinterpreters significantly outperformed threading and multiprocessing. One example, a simple web service that performed some CPU-bound work, maxed out at 100 requests per second with threads, and 600 with multiprocessing. But with subinterpreters, it yielded 11,500 requests, and with little to no drop-off when scaled up from one client. The interpreters module has very limited functionality right now, and it lacks robust mechanisms for sharing state between subinterpreters. But Snow believes by Python 3.13 a good deal more functionality will appear, and in the interim developers are encouraged to experiment...
Python 3.11 introduced new bytecodes to the interpreter, called adaptive instructions. These instructions can be replaced automatically at runtime with versions specialized for a given Python type, a process called quickening. This saves the interpreter the step of having to look up what types the objects are, speeding up the whole process enormously. For instance, if a given addition operation regularly takes in two integers, that instruction can be replaced with one that assumes the operands are both integers... Python 3.12 has more adaptive specialization opcodes...
And starting with Python 3.12, object headers now use 96 bytes, which InfoWorld reports is "slightly less than half of what it was before."
Utah? (Score:1)
Why would anyone hold a convention in Utah?
Re: (Score:1)
Wow they can serve real beer now too! Amazing!
Re: Utah? (Score:2)
Why anyone even have a conversation in Utah?
Good (Score:3, Interesting)
A much-needed cleanup. Of course, Python will never be "high performance", but for a lot of things it is good enough and most coders cannot do "high performance" anyways.
Re:Good (Score:4, Interesting)
Yep. We do a lot of data analysis at work, and we've had slow algorithms where I've gone and taken it and rewritten it in C++ and the speedup wasnt substantial because the majority of the work was done in well optimized libraries anyway. However theres always going to be a category of algorithms where its the actual high level of the algorithm that slows it down and while some just need to be rewritten to purge the stupid, some genuinely benefit from a faster runtime. Considering the plethora of science and math libraries in python , its in everyones interest to figure out where the snares are in python. (afaik its mostly in the typing system, which recent advances in static explicit types have helped but yeah. [issues with GIL havent been much of a practical issue in quite some time, its there, but its largely tamed by libraries such as multithreading)
Re: (Score:2)
Choose one: quick coding, cheap hardware, fast processing.
Though Python does offer ease in duct taping something functional quickly, multipurpose languages are not good at evaluating large analysis datasets speedily. This is where R, or better, SAS come into play. Also, there is only so much one can do from a performance standpoint on X86 hardware.
Re:Good (Score:4, Insightful)
How is R faster than Python? You can absolutely evaluate large datasets in the Python ecosystem. Note that I said ecosystem, not just Python. There is a native Python module for just about everything. If I want language level speed, I would use Julia, but R and SAS aren't built for speed anymore than Python is.
I use R for exploring data, simply because I find statistical and plotting code quicker in it. The reason isn't computational speed.
Re: (Score:2)
If you're looking for flexibility in large dataset processing, and native languages aren't something you're... proficient in, JIT Python is king.
And I say that strongly holding my nose.
Re: (Score:2)
Yeah, I get that
Re: (Score:2)
You do not seem to have much experience with large-scale data analysis. What you claim could be straight out of a marketing brochure making bogus claims to rope in customers.
Re: (Score:3)
Also, there is only so much one can do from a performance standpoint on X86 hardware.
Before amd64, x86 dominated the top500. You have no idea what you're talking about at all.
Re: (Score:2)
Re: (Score:2)
To put some perspective on this, AMD64 actually slows down execution by some four to ten or so percent, depending on how pointer-heavy the application is, because of the added memory bandwidth for the pointers.
AHAHAHHAHAHAHA NO
Just recompiling code for amd64 produces a ~15% average improvement in execution time on amd64 processors because of the reduced number of operations it takes to shovel data around, and to a lesser degree due to the increased number of registers — though register renaming on x86 already made that largely irrelevant to performance — the fact that x86 has zero general purpose registers since operands have to be in specific registers for so many operations was a big problem before
Re: (Score:2)
Or choose none, depending on how bad you are at your job.
It's not insight, it's dogma, and it comes from ignorance.
Re: (Score:2)
Indeed. People that do not understand things, but cannot see or admit that, typically go for dogma. It is rather pathetic in anybody working in technology.
Re: Good (Score:2)
Science bitches!!
Re: (Score:2)
"However theres always going to be a category of algorithms where its the actual high level of the algorithm that slows it down..."
LOL couldn't prove you're not a programmer any more clearly.
The fact that high performance code is isolated to libraries has always been the glaring evidence of just how bad Python performance is.
Re: (Score:2)
Just facepalm.
Hint: those libraries can be used from any language.
In other words: their existence has nothing to do with Python.
Lucky that opinions like yours show us how irrelevant you are as:
- a programmer
- a scientist
Re: (Score:2)
Unless it is something that absolutely needs to run as fast as possible, damn the costs, Python is a perfectly fine language. If you just need to write something to answer a question once, Python probably gets you there faster even if the program executes slower.
Raises hand ... (Score:5, Funny)
'Faster, Leaner' Python
Wouldn't that just be Perl? :-)
Re: (Score:3)
No, that would be Julia, if you are looking outside Python versions.
Re: (Score:3)
No. Perl is faster and the executable is smaller, but in order to make Python like perl, you'd have to not just make it faster, you'd have to make it funner.
Think of some more rigid language for your comparison. Really just about any of them, will work -- whatever you pick, it's probably faster than python. As in :-)"
"Wouldn't that just be RPG?
Re: (Score:2)
Perl is faster and the executable is smaller, but in order to make Python like perl, you'd have to not just make it faster, you'd have to make it funner.
Writing python is more unfun than writing perl. Neither one is really party time though.
Reading python is more fun than reading perl, on average.
Re: (Score:2)
No, Python is readable.
really? (Score:5, Funny)
"Quickening"?
Why do the people developing Python have such a need to invent new words for already-established ideas? The rest of the world calls this particular idea specialization, and it's decades old.
Re: really? (Score:2)
Not a fan of Highlander, are you?
Re: really? (Score:2)
Re: really? (Score:2)
Re: (Score:2)
"Quickening"?
Why do the people developing Python have such a need to invent new words[...]?
I would not consider it a new word so much as an archaic one.
Alpha version (Score:5, Informative)
Python 3.12 was released today
Python 3.12.0 alpha 7 was released today. The official release of 3.12.0 is slated for 2 October 2023 [python.org].
Re:Alpha version (Score:5, Informative)
Yeah, what the heck is with this post?
Not only is 3.12 not being released until Q4 but all the items in the article aren't even slated for 3.12 afaict. The "interpreters" module they mention seems to be PEP 554 (https://peps.python.org/pep-0554/) which is labeled as targeted for 3.13 and is nowhere mentioned in the linked "what's new in 3.12" page. It is also not among the ones mentioned as still being considered for inclusion before the 3.12 feature freeze in ~ a week ( https://discuss.python.org/t/p... [python.org] )
The "separate GIL per sub-interpreter" is PEP-684 (https://peps.python.org/pep-0685) and IS accepted for 3.12 according to its page and the message it links to. (https://discuss.python.org/t/pep-684-a-per-interpreter-gil/19583/40) though it still hasn't made it to the "what's new in 3.12" page. This is pretty cool as some future speedup of the multiprocessing module, But w/o 554 it still won't be accessible from python code.
Re: Retarded language (Score:2)
You tell em, Steve Dave!
Re: Retarded language (Score:3)
Granted, significant whitespace seems ugly as hell at first. This is what seriously put me off python when I started with it. It just felt wrong.
But the mandatory whitespace is exactly the same as the non-mandatory whitespace every sane programmer already uses in pretty much every language. You will never get in a position where code is near impossible to read because it's indented wrong. It saves wasting lines on constructs that are already contained in the indentation level. It's not wrong, it's just diff
Re: (Score:3)
... as long as everyone uses the same editor to write Python code. But use an editor that has a different idea about inserting tabs vs spaces and your code blocks will be invisibly wrong. (But, hey, that can be fixed by just forcing every editor in the world to cater to Python's wacky idea.)
The biggest problem with Python, though, is the programmers. I worked on the C++ data-processing layer underneath a Python app, and most of the data passed around by the Python code was lists. Or sometimes tuples. Ev
Re: (Score:1)
... as long as everyone uses the same editor to write Python code. But use an editor that has a different idea about inserting tabs vs spaces and your code blocks will be invisibly wrong. (But, hey, that can be fixed by just forcing every editor in the world to cater to Python's wacky idea.)
The biggest problem with Python, though, is the programmers. I worked on the C++ data-processing layer underneath a Python app, and most of the data passed around by the Python code was lists. Or sometimes tuples. Events with a source, session, event type and associated data? A list! Mix up the type of a list element, and you get a runtime error at some odd place in the code because it caused problems when the wrongly-typed data was used, not written. The Python coders couldn't be bothered to write a type for events, or maybe they were concerned about the field lookup costs.
That was exacerbated, of course, by Python's delayed type checking rules. I am not sure who thought strict(-ish) runtime type checking could possibly work out well, but it fails at any non-trivial scale of code. Types don't have to be explicit in most places -- see ML for an example -- but if they are strict, they should be checked at compilation time.
Let me summarize: bad Python code is bad. No shit Sherlock. Hey, guess what: bad C++ code is bad too.
And yes, C++ kind of forces you to avoid this particular kind of bad that you described, but at the cost of allowing other kind of bad. Ever tried to deal with code written by someone who thinks he's good at template metaprogramming (except for the most basic lesson: knowing when NOT to use it)?
Re: (Score:2)
the mandatory whitespace is exactly the same as the non-mandatory whitespace every sane programmer already uses in pretty much every language.
No, it isn't. Even sane programmers sometimes use a differing indent strategy for a particular bit of code in order to increase legibility, because it does so for that particular piece.
You will never get in a position where code is near impossible to read because it's indented wrong.
No, instead you get in a position where code is near impossible to fix because the indentation is lost for some dumb reason and therefore it breaks.
Re: (Score:2)
None of this is correct, despite the conclusions being true. It is both wrong and different, but not a big issue. Python sucks because of its terrible performance, not its whitespace fascism.
Re: (Score:2)
The wrong part of syntactic whitespace as implemented in Python is that there is no way to override it.
Meaning, there is no way to explicitly construct a block, like in nearly every other language. And, by extension, there's no way to create a new scope except through a function definition. Both of those are mistakes.
The ultra-rigid implementation in Python also means that if you copy-paste or comment-out a region of code, it probably won't do what you would want it to do. That fundamental debugging tool
BETA released today, final release in Oct 2023 (Score:1)
Python programmers, check Mojo! (Score:2)
Luajit (Score:2)
So what you're saying is (Score:2)
You built it better, stronger, faster [youtube.com].
Did they finally fix the indent mayhem? (Score:2)
Or is Emperor Guido still sticking to his government provided 40 column CTR utopia?
old is new again (Score:2)
>
Snow's own initial experiments with subinterpreters significantly outperformed threading and multiprocessing. One example, a simple web service that performed some CPU-bound work, maxed out at 100 requests per second with threads, and 600 with multiprocessing. But with subinterpreters, it yielded 11,500 requests, and with little to no drop-off when scaled up from one client.
lol they invented mod_perl
Re: (Score:2)
lol they invented mod_perl
Yeah, but still slower. With real, consistent effort they may get Python to the point where it is half as fast!
The slow bit... (Score:1)
Re: (Score:2)
I understand that with 3.10 they tried to have coordination with some of the major libraries to have them release updates at about the same time as 3.10 went out.
As far as I can tell, that effort was not very successful, as some of the primary libraries I use still haven't caught up.
why sub-interpreters faster than multiprocessing? (Score:1)