10 ms·
Python 3.11 Delivers
- wartijn_ 4y agoSome context from one of the replies to that tweet: > This is a graph of CPU utilization for the web services that power PyPI. Today we upgraded from 3.10 to 3.11 and saw a significant and correlated drop in CPU usage -- nearly half. > > The CPython team has been putting a lot of effort into improving performance recently and it shows!
- bombolo 4y ago
- JoachimS 4y agoPerhaps. That still doesn't mean that this is a major improvement.
- polotics 4y agoIf you have some substantive insight about the code in https://github.com/pypi/warehouse https://github.com/pypi/warehouse please post your ideas in https://pypi.org/help/#feedback https://pypi.org/help/#feedback ;-)
- vkazanov 4y agoIf you're talking about the older approach to implementation CPython used to take then I must say if was pretty efficient for what it did (all while keeping the code clean). It took a 2-3 days deep dive for a moderately prepared programmer to understand ins/outs of the interpreter. Optimisations coming to Python are a departure from the "clean-first code" approach. It's performance coming at a price of complexity.
- gpderetta 4y agoand it was about time!
- deleted 4y ago[deleted]
- bonzini 4y agoI have done some benchmark recently of Python 3.11, and pure Python code was even beating a Python-wrapped C++ implementation of the same data structure. While it's not an entirely apples-to-apples comparison (the reason to use C++ was to enable running without the global interpreter lock), it is still very impressive.
- noloblo 4y agoDo you mind sharing Which python wrapped cpp implementation you might have done the benchmark comparison on ?
- mkoubaa 4y agoPython wrapping using binding tools like swig or cython or boost python are bound to be slower for things like data structures. They bring with them a lot of overhead between the python interpreter and the call into the data structure
- bonzini 4y agoIt's at https://github.com/bonzini/vrc https://github.com/bonzini/vrc. The wrapper is Cython-based.
- pjmlp 4y agoIn the early Android days, Dalvik did quite a poor job generating native code, so many math functions went through JNI into native code. Eventually Dalvik got replaced with ART, Android team started to care about JITing and AOT compilation, and all those native methods got deprecated as JIT/AOT code out of pure Java implementation started to be faster than the cost to jump through FFI infrastructure.
- josteink 4y agoI'm no big fan of python in general, but if this can help getting the slow python-based apps I depend on to run faster... I'm all for it :)
- anakaine 4y agoI develop scripts, and a few minor but important-to-my-business scientific apps in Python due to library support. I'm quite excited. We already wrangle as much performance as we can out of our approaches, so anything that speeds up actual execution is awesome.
- shanebellone 4y agoPython is wonderful in many scenarios and terrible in others. I'm curious to know which python-based apps you're using.
- josteink 4y agoI guess I've eliminated quite a few of them over the years. The biggest one remaining is probably matrix-synapse.
- hprotagonist 4y agolitecli, pgcli, docker-compose, visidata, ranger, yt-dlp, aws-cli, …
- InvaderFizz 4y agodocker-compose is now golang based.
- hprotagonist 4y agohmm, so it is. I still have the one i installed from pypi though.
- rbanffy 4y agoAnd there is a huge chance the slowness of the others is due to whatever they are connecting to.
- melony 4y agoI usually use https://www.taichi-lang.org/ https://www.taichi-lang.org/ when I need to speed up the code.
- nevernever 4y ago
- jamespo 4y agoThank you for that, I had never heard of it
- yuanminghu 4y agoWelcome to give it a shot and let the Taichi community know how you fell about it :-)
- mkl 4y agoThat can only accelerate a very limited subset of Python code. For numerical calculations it looks promising, but for a codebase like PyPI's it's probably no use at all.
- yuanminghu 4y agoRight - I'd say Taichi was not designed to accelerate the entire Python codebase. In fact, since Taichi needs to run to GPUs, supporting a very wide range of dynamic features of Python would go in the opposite direction of its original goal (faster compute-intense code such as numerical simulations). Back to the main thread, I'd say the acceleration in Python 3.11 would benefit Taichi users too - there are still parts of Taichi that runs in Python (such as constructing the AST of computation kernels), which will run faster with 3.11.
- nurettin 4y agoThis introduces a completely new value stack which is only accessible from taichi and it takes a lot of hacking to pass python objects back and forth between taichi and python so anything you write, you will have to rewrite pretty much everything. It is not just adding a simple decorator to speed things up if your program is just a little more complex than summing numbers.
- choeger 4y agoHow long until we'll eat that gain with another level of abstraction?
- terminalcommand 4y agoThe biggest hurdle I think is still the GIL. Does anyone know if any progress is being made there? https://wiki.python.org/moin/GlobalInterpreterLock https://wiki.python.org/moin/GlobalInterpreterLock
- oblio 4y agoI think there were some initiatives, but I don't know if they're still ongoing. Unladen Swallow from Google didn't succeed.
- morelisp 4y agoI believe the plan is still that the improvements in 3.11 are to be traded off against the overhead of eventual GIL removal. So, don't enjoy them too much.
- mkoubaa 4y agoGil free python would break a lot of oss packages written with the C API that are only thread safe because if the GIL. Couple that with the fact that python on its own without packages isn't that useful and you can see why this is going to be a challenge . Multiple interpreters in the same process with their own locks is happening now, though
- lzauz 4y ago>Gil free python would break a lot of oss packages written with the C API that are only thread safe because if the GIL. So make it a runtime option. It's getting tiresome that python performance is suffering because some can't be bothered to write thread-safe software. In 2022.
- coldtea 4y ago
- asicsp 4y agoRelated discussions: * "Python 3.11 is faster than 3.8" https://news.ycombinator.com/item?id=33345421 https://news.ycombinator.com/item?id=33345421 (378 points | 49 days ago | 294 comments) * "Python 3.11 Performance Benchmarks Are Looking Fantastic" https://news.ycombinator.com/item?id=31640049 https://news.ycombinator.com/item?id=31640049 (234 points | 6 months ago | 85 comments)
- taf2 4y agoThis is great news - we're deploying some new AI models and this coupled with Ruby 3.2 (yjit) I beleive we can deliver for the first time in a few years a new feature supported by new servers without increasing costs (we'll see, but i have hope)
- bratao 4y agoI´m loving the Faster CPython project. Just for a reference, I have a project originally written in (very optimized) Python, that has a Rust module for the demanding path. The Rust version was approximately 150% faster in Python 3.10. In Python 3.11 the gap reduced to 100% faster. This is something incredible as I would prefer to keep it all in Python.
- eyegor 4y agoHave you tried running it in pypy? Or using @njit in numba? I've found both to be faster than cpython. Of course there's also cython if you're brave but that tends to be a lot more work.
- nickjj 4y agoIn one project I have with a few hundred tests, after updating to Python 3.11 I noticed my test suite's runtime speed got faster by about 8-10%. That's using pytest in a Flask app where most tests are doing "real'ish" things like visiting one of the site's endpoints using the Flask test client and accessing Postgres. Not bad at all for a 1 line change.
- jerrygenser 4y agoThis workload seems IO bound so python 3.11 shouldn't add too many speedups here, it adds mostly cpu-bound improvements. Surprised you are getting speedsup - any idea which parts?
- nickjj 4y agoI haven't done any low level profiling. I ran my test suite 5 times with 3.10 and then I did the same after updating to 3.11. It was an extremely informal test but 3.10 consistently took about 25 seconds where as 3.11 was finishing in 23. It is I/O bound but it's all localized. Those URL endpoints aren't making external API calls. For tests, Postgres is set to use Session.begin_nested with SQLAlchemy which takes advantage of Postgres' ability to use SQL SAVEPOINTs[0]. The gory details are above my paygrade (I found it while Googling), but the end result is it makes Postgres able to be really really fast when accessing your DB in tests. I don't think it really writes to disk but it makes your app think it did and you get the "true" outcome of running the SQL (ids get created, all of your SQL works as expected, etc.). It's not a mock. [0]: https://docs.sqlalchemy.org/en/20/orm/session_transaction.html#using-savepoint https://docs.sqlalchemy.org/en/20/orm/session_transaction.ht...
- deleted 4y ago[deleted]
- deleted 4y ago[deleted]
- coldtea 4y agoWell, most of the time would be on the requests and db query side, not Python
- oblio 4y ago
- melling 4y agoEver feel like we still live in the Dark Ages where people jump to all sorts of conclusions without offering any evidence? That innuendo thing you’re doing is all the rage these days.
- tomrod 4y agoWe are more informed these days than ever. This suggests it's always been this way, we are simply more likely to catch it now.
- sho_hn 4y agoWhat's disturbing is the numbing effect it seems to have. Bad behavior is increasingly on display for all to see -> We're all slowly realizing it's always been this bad, it's just more visible now -> We're kind of just becoming OK with all the noise. Cf. blatantly wrong statements divorced from reality from major figures on social media, etc. That said, I'm not sure whether OP is really in that weight class. It's just a "did direction change with a leadership change?" question that can be answered in a straight-forward manner by closer observers or those with first-hand experience. The danger is that others take a possibly wrong narrative forward by taking the question and ignoring the answer, in a "Have you stopped beating your wife?" sort of way.
- oblio 4y ago> Cf. blatantly wrong statements divorced from reality from major figures on social media, etc. I'm just a random guy on a random forum :-))))
- deleted 4y ago[deleted]
- oblio 4y ago
- pen2l 4y agoAnd there's yet more speed-ups coming in Python 3.12! It'll support Perf profiler to allow looking into Python call stacks and see python functions in perf output and have even more improved error messages. https://docs.python.org/dev/whatsnew/3.12.html https://docs.python.org/dev/whatsnew/3.12.html
- eyegor 4y agoIf you're interested in profiling, you should check out scalene. It's leaps ahead of every other profiling tool I've used in python and honestly might be the best profiler I've used in any language. It will give you per line results for mem, cpu, and gpu, tell you c time vs python time (numpy calls, etc), and it's faster than most other python profilers. https://github.com/plasma-umass/scalene https://github.com/plasma-umass/scalene
- _whiteCaps_ 4y agoThere's a good demo of it here: https://www.youtube.com/watch?v=vVUnCXKuNOg https://www.youtube.com/watch?v=vVUnCXKuNOg
- deleted 4y ago[deleted]
- benreesman 4y agoI’ve been more and more impressed by the python runtime, which is getting pretty slick. The packaging story seems less, uh, put together. Is any consensus forming on that?
- rmorey 4y agoI think poetry is emerging as a consensus somewhat, and it’s been the most reliable tool in my experience
- jerrygenser 4y agodependency resolution even with caching takes way too long for larger projects, which requires a lot of setup and configuration when managing multiple inter-related projects that have many dependencies
- woodson 4y agoI really hope not. I used it for a while, but the “wontfix” attitude (e.g. PEP440 related issues: https://github.com/python-poetry/poetry/issues/6013 https://github.com/python-poetry/poetry/issues/6013, or the issues with pytorch cpu packages) made me go back to regular pip and use “pip freeze” for locking package versions in place.
- DangitBobby 4y agoThat is really unfortunate.
- tomnipotent 4y agoThe PEP440 issue you linked to is a positive for Poetry, not a negative. You shouldn't be installing packages into your distro-managed Python environment, that's just asking for problems.
- woodson 4y agoThis issue is not restricted to installing packages into your distro-managed Python environment. I had Poetry-managed environments that, after upgrading to poetry>=1.2.0 stopped working (e.g., I couldn't run "poetry update" anymore) because of these issues. I don't treat Python packaging tools as my religion. If one doesn't fulfill its purpose, I use another solution. Whether that's a positive or negative for the tool isn't my concern.
- Bluecobra 4y agoI wonder if this is a big enough carrot to get people to move off Python 2.7.
- SergeAx 4y agoFWIW, they have much bigger carrot near their non-business end for years now, and if it is not persuasive enough - I don't know what is.
- boxed 4y agoThere was a pretty big performance improvement jump to 3.9 already.
- szatkus 4y agoEven 3.5 is noticebly faster than 2.7 last time I checked.
- stusmall 4y agoIf someone is using a component that important that far outside its EOL it isn't a performance issue. It's either something extremely legacy, massively underbudgeted, or maybe non-internet-facing and non-critical. It isn't the kind of project someone is fine tuning for high performance.
- abraxas 4y agoI’m still unsure I understand the source of excitement. As far as I know Python even in its latest version is still at least an order of magnitude slower than native compiled code. It would seem to me that a native Python compiler would benefit server side Python applications much more than these incremental speed improvements of the interpreter. Is there any work being done by the Python community in that direction? For CPU bound workloads Python needs 10-100x improvement in order to be competitive. Note, that I’m not dumping on Python. I use it daily but I think it’s likely a poor choice for apps that primarily tax the CPU.
- smcl 4y agoThere have been a bunch of attempts to produce compiled code for Python, but each have fallen short in different ways. However there is a serious bit of effort going into speeding up CPython now. I don’t think it’ll result in turning it into an optimising compiler that produces a binary executable as output or even an interpreter w/ JIT compiler, but I think there are still gains to be made without committing to either of those routes
- nerdponx 4y ago> in order to be competitive. In order to be competitive with what?
- abraxas 4y agoServer side systems that do a lot of CPU bound compute. I'm thinking Spark, Flink, that kind of stuff.
- nerdponx 4y agoI don't think that's ever been a goal of Python, and it's not what people use (or should use) Python for. Making Python faster is great because it improves every existing use case for Python, not because it now makes Python a good choice for situations where it wasn't previously a good choice.
- jiaaro 4y ago
- mark_l_watson 4y agoI am writing a Python AI book right now and I am using version 3.11. Since I am a patient person, I prefer conda to avoid dependency issues, so: conda create --name py3.11 python=3.11 -c conda-forge Being a Lisp developer (for 40 years), I am finally developing some love for Python after years of having to use it at work for deep learning. For me the better performance/lower resource improvements in 3.11 (looking forward to 3.12) is a big issue because I compare to Common Lisp performance, which can be very good. Off topic, but my new found love for Python comes from realizing that many programming tasks can be done so much faster in Python.
- rbanffy 4y ago> many programming tasks can be done so much faster in Python. Same here. I came to Python because I'm lazy ;-) I stayed because the language is elegant and the community is simply outstanding.
- pjmlp 4y agoAs someone that knows Python since version 1.6, that is what kind of always has irritated me. Sure the language isn't Lisp, but it comes close enough, only to be let down by lack of performance focus, and PyPy never got the spotlight it deserves. So I kept using Python only for sysadmin stuff when targeting UNIX like workflows. Finally, it is looking like I can eventually some day reach out for Python in tasks where performace matters.
- kneebonian 4y ago> Off topic, but my new found love for Python comes from realizing that many programming tasks can be done so much faster in Python. Wait till you get ahold of ruby. It is the most LISP like language I've found yet in terms of flexibility and what it can do for you.
- freedomben 4y agoRuby is definitely great and I would have totally agreed a couple years ago, but Elixir has blown my mind. It feels so much like LISP sometimes I wonder, especially with the full macro system where you can operate directly on the AST :-D Given the recent news on Nx and Livebook, Elixir may be a first-class language for ML very soon. On a related note, Elixir feels a bit like a functional love child of ruby and python.
- drchaim 4y agoInitial tests in a medium size codebase shows a 15% speed improvement, both in speed and some platform benchmarks. which is great. kudos to the team working on this.