[HN Gopher] State of Python 3.13 performance: Free-threading
___________________________________________________________________
State of Python 3.13 performance: Free-threading
Author : art049
Score : 87 points
Date : 2024-11-05 13:06 UTC (9 hours ago)
(HTM) web link (codspeed.io)
(TXT) w3m dump (codspeed.io)
| eigenspace wrote:
| I don't really have a dog in this race as I don't use Python
| much, but this sort of thing always seemed to be of questionable
| utility to me.
|
| Python is never really going to be 'fast' no matter what is done
| to it because its semantics make most important optimizations
| impossible, so high performance "python" is actually going to
| always rely on restricted subsets of the language that don't
| actually match language's "real" semantics.
|
| On the other hand, a lot of these changes to try and speed up the
| base language are going to be highly disruptive. E.g. disabling
| the GIL will break tonnes of code, lots of compilation projects
| involve changes to the ABI, etc.
|
| I guess getting loops in Python to run 5-10x faster will still
| save some people time, but it's also never going to be a
| replacement for the zoo of specialized python-like compilers
| because it'll never get to actual high performance territory, and
| it's not clear that it's worth all the ecosystem churn it might
| cause.
| willvarfar wrote:
| (As a happy pypy user in previous jobs, I want to chime in and
| say python _can_ be fast.
|
| It can be so fast that it completely mooted the discussions
| that often happen when wanting to move from a python prototype
| to 'fast enough for production'.)
| eigenspace wrote:
| PyPy is still slow compared to actual fast languages. It's
| just fast compared to Python, _and_ it achieves that speed by
| not being compatible with most of the Python ecosystem.
|
| Seems like a lose-lose to me. (which is presumably why it
| never caught on)
| rowanG077 wrote:
| What isn't compatible with PyPy? I can run large frameworks
| using pypy no problem. There certainly will be package that
| aren't compatible. But far and away most of the ecosystem
| is fully comaptible.
| artemisart wrote:
| This depends a lot on your domain, e.g. pypy is not
| compatible with pytorch or tensorflow so DL is out of the
| picture.
| rmbyrro wrote:
| Python 3.12 will be officially supported until October 2028, so
| there's plenty of time to migrate to no-GIL if anyone wants to.
| zurfer wrote:
| Python 3.13 is not removing the GIL. You just have an option
| to run without it.
| the__alchemist wrote:
| This is a good question, and I think about it as well. My best
| guess for a _simple_ explanation: Python is very popular; it
| makes sense to improve performance for python users, given many
| do not wish to learn to use a more performant language, or to
| use a more performant Python implementation. Becoming
| proficient in a range of tools so you can use the right one for
| the right job is high enough friction that it is not the path
| chosen by many.
| eigenspace wrote:
| Oh yeah, I totally get the motivation behind it. It's always
| very tempting to want to make things faster. But I can't help
| but wondering if these attempts to make it faster might end
| up just making it worse.
|
| On the other hand though, Python is so big and there's so
| many corps using it with so much cash that maybe they can get
| away with just breaking shit every few releases and people
| will just go adapt packages to the changes.
| dagmx wrote:
| Python famously has a community that does NOT adapt to
| changes well. See the Python 2 to 3 transition.
| eigenspace wrote:
| Python's community was significantly smaller and less
| flushed with cash during the 2 to 3 transition. Since
| then there has been numerous 3.x releases that were
| breaking and people seem to have been sucking it up and
| dealing with it quietly so far.
|
| The main thing is that unlike the 2 to 3 transition,
| they're not breaking syntax (for the most part?), which
| everyone experiences and has an opinion on, they're
| breaking rather deep down things that for the most part
| only the big packages rely on so most users don't
| experience it much at all.
| dagmx wrote:
| I disagree with this entire comment.
|
| The Python community consisted of tons of developers
| including very wealthy companies. At what point in the
| last few years would you even say they became "rich
| enough" to do the migration? Because people are STILL
| talking about trying to fork 2.7 into a 2.8.
|
| I also disagree with your assertion that 3.x releases
| have significant breaking changes. Could you point to any
| specific major breaking changes between 3.x releases?
|
| 2 to 3 didn't break syntax for most code either. It
| largely cleaned house on sensible API defaults.
| eigenspace wrote:
| Fair enough. You may be totally right here, as I
| mentioned I don't use Python much at all since like 2017
| and haven't paid it much attention in a while. I retract
| my comment.
|
| Regarding breakage in 3.x, all I know is that I recall
| several times where I did a linux system update (rolling
| release), and that updated my Python to a newly released
| version which broke various things in my system. I'm
| pretty sure one of these was v3.10, but I forget which
| others caused me problems which I could only solve by
| pinning Python to an older release.
|
| It's entirely possible though that no actual APIs were
| broken and that this was just accidentaly bugs in the
| release, or the packages were being naughty and relying
| on internals they shouldn't have relied on or something
| else.
| dagmx wrote:
| To your last point: it's neither the language nor the
| packages but rather it's the ABI.
|
| Python isn't fully ABI stable (though it's improved
| greatly) so you can't just intermix compiled dependencies
| between different versions of Python.
|
| This is true for many packages in your distro as well.
| eigenspace wrote:
| Ah I see. Yeah, I guess I just think that for a language
| that's so dependent on FFI, instability in the ABI is
| defacto instability in the language as far as I'm
| concerned. But I understand that not everyone feels the
| same.
|
| Almost every major noteworthy Python package uses the
| ABI, so instability there is going to constantly be felt
| ecosystem wide.
| dbsmith83 wrote:
| There have been many breaking changes throughout python
| 3.x releases:
|
| - standard library modules removed
|
| - zip error handling behaves differently
|
| - changes to collections module
|
| - new reserved keywords (async, await, etc.)
|
| You can argue how big of a deal it is or isn't, but there
| were definitely breakages that violate semantic
| versioning
| eigenspace wrote:
| They removed entire standard library modules? Wut.
| wruza wrote:
| _Could you point to any specific major breaking changes
| between 3.x releases?_
|
| I can not, but I can tell you that anything AI often
| requires finding a proper combination of python + cuXXX +
| some library. And while I understand cu-implications, for
| some reason python version is also in this formula.
|
| I literally have four python versions installed and
| removed from PATH, because if I delete 3.9-3.11, they
| will be needed next day again and there's no meaningful
| default.
| dagmx wrote:
| Those are ABI changes and not changes to the language.
| wruza wrote:
| If these were just ABI changes, packagers would simply
| re-package under a new ABI. Instead they specify ranges
| of versions in which "it works". The upper end often
| doesn't include the last python version and may be
| specified as "up to 3.x.y" even.
|
| Sure I'm not that knowledgeable in this topic (in
| python). But you're telling me they go to the lengths of
| supporting e.g. 3.9-3.11.2, but out of lazyness won't
| just compile it to 3.12?
|
| I can only hypothesize that 3.9-3.xxx had the same ABI
| and they don't support multiple ABIs out of principle,
| but that sounds like a very strange idea.
| adamc wrote:
| 2 to 3 broke lots of code. Print became a function.
| Imports moved around. And there were subtle changes in
| the semantics of some things. Famously, strings changed,
| and that definitely affected a lot of packages.
|
| Quite a bit of that could be fixed by automated tooling,
| but not all of it, and the testing burden was huge, which
| meant a lot of smaller packages did not convert very
| quickly and there were ripple effects.
| dagmx wrote:
| Yes 2 to 3 changed things. We're discussing what changed
| in between different versions of 3.
| hawski wrote:
| Most of those are some old long deprecated things and in
| general those are all straight up improvements. Python is
| not my main thing so I'm not really good to answer this,
| but I listed a few that I am sure triggered errors in
| some code bases (I'm not saying they are all _major_ ).
| Python's philosophy makes most of those pretty easy to
| handle, for example instead of foo now you have to be
| explicit and choose either foo_bar or foo_baz. For
| example in C there still is a completely bonkers function
| 'gets' which is deprecated for a long time and it will be
| there probably for a long time as well. C standard
| library, Windows C API and Linux C API to large extent
| are add only, because things should stay bug-to-bug
| compatible. Python is not like that. This has its perks,
| but it may cause your old Python code to just not run. It
| may be easy to modify, but easy is significantly harder
| than nothing at all.
|
| https://docs.python.org/3/whatsnew/3.3.html#porting-to-
| pytho...
|
| > Hash randomization is enabled by default. Set the
| PYTHONHASHSEED environment variable to 0 to disable hash
| randomization. See also the object.__hash__() method.
|
| https://docs.python.org/3/whatsnew/3.4.html#porting-to-
| pytho...
|
| > The deprecated urllib.request.Request getter and setter
| methods add_data, has_data, get_data, get_type, get_host,
| get_selector, set_proxy, get_origin_req_host, and
| is_unverifiable have been removed (use direct attribute
| access instead).
|
| https://docs.python.org/3/whatsnew/3.5.html#porting-to-
| pytho...
|
| https://docs.python.org/3/whatsnew/3.6.html#removed
|
| > All optional arguments of the dump(), dumps(), load()
| and loads() functions and JSONEncoder and JSONDecoder
| class constructors in the json module are now keyword-
| only. (Contributed by Serhiy Storchaka in bpo-18726.)
|
| https://docs.python.org/3/whatsnew/3.7.html#api-and-
| feature-...
|
| > Removed support of the exclude argument in
| tarfile.TarFile.add(). It was deprecated in Python 2.7
| and 3.2. Use the filter argument instead.
|
| https://docs.python.org/3/whatsnew/3.8.html#api-and-
| feature-...
|
| > The function time.clock() has been removed, after
| having been deprecated since Python 3.3: use
| time.perf_counter() or time.process_time() instead,
| depending on your requirements, to have well-defined
| behavior. (Contributed by Matthias Bussonnier in
| bpo-36895.)
|
| https://docs.python.org/3/whatsnew/3.9.html#removed
|
| > array.array: tostring() and fromstring() methods have
| been removed. They were aliases to tobytes() and
| frombytes(), deprecated since Python 3.2. (Contributed by
| Victor Stinner in bpo-38916.)
|
| > Methods getchildren() and getiterator() of classes
| ElementTree and Element in the ElementTree module have
| been removed. They were deprecated in Python 3.2. Use
| iter(x) or list(x) instead of x.getchildren() and
| x.iter() or list(x.iter()) instead of x.getiterator().
| (Contributed by Serhiy Storchaka in bpo-36543.)
|
| > The encoding parameter of json.loads() has been
| removed. As of Python 3.1, it was deprecated and ignored;
| using it has emitted a DeprecationWarning since Python
| 3.8. (Contributed by Inada Naoki in bpo-39377)
|
| > The asyncio.Task.current_task() and
| asyncio.Task.all_tasks() have been removed. They were
| deprecated since Python 3.7 and you can use
| asyncio.current_task() and asyncio.all_tasks() instead.
| (Contributed by Remi Lapeyre in bpo-40967)
|
| > The unescape() method in the html.parser.HTMLParser
| class has been removed (it was deprecated since Python
| 3.4). html.unescape() should be used for converting
| character references to the corresponding unicode
| characters.
|
| https://docs.python.org/3/whatsnew/3.10.html#removed
|
| https://docs.python.org/3/whatsnew/3.11.html#removed
|
| https://docs.python.org/3/whatsnew/3.12.html#removed
| dagmx wrote:
| Thanks. That's a good list, though I think the majority
| of the changes were from deprecations early in the 3.x
| days and are API changes, whereas the OP was talking
| about syntax changes for the most part.
| eigenspace wrote:
| No I wasn't?
| dagmx wrote:
| Maybe i misunderstood your argument here where you scope
| it tightly to syntax changes being an issue but internal
| changes being fine.
|
| https://news.ycombinator.com/item?id=42051745
| eigenspace wrote:
| What I meant by that is that because the changes mostly
| aren't syntax changes, they won't upset most users who
| are just using big packages that are actively maintained
| and keeping ahead of the breakage.
|
| But I still find the high level of instability in Python
| land rather disturbing, and I would be unhappy if the
| languages I used constantly did these sorts of breaking
| changes
|
| I'm even more extreme in that I also think the ABI
| instability is bad. Even though Python gives no guarantee
| of its stability, it's used by so many people it seems
| like a bad thing to constantly break and it probably
| _should_ be stabilized.
| Yossarrian22 wrote:
| Are there communities that handle such a change well? At
| least that went better than Perl and Raku
| dagmx wrote:
| Anything where the language frontend isn't tied to the
| ABI compatibility of the artifacts I think. They can mix
| versions/editions without worry.
|
| I think it's a larger problem with interpreted languages
| where all the source has to be in a single version. In
| that case I cant think of much.
| adamc wrote:
| That was, in many ways, a crazy difficult transition. I
| don't think most languages have gone through such a
| thing. Perl tried and died. So I don't agree that it
| reflects poorly on the community; I think the plan itself
| was too ambitious.
| dagmx wrote:
| Many languages have. There were significant breaks in C++
| when stringabi changed, Swift has had major language
| changes, rust has editions.
|
| The difference is in what motivates getting to the other
| end of that transition bump and how big the bump is.
| That's why it took till past 2.7's EOL to actually get
| people on to 3 in a big way because they'd drag their
| feet if they don't see a big enough change.
|
| Compiled languages have it easier because they don't need
| to mix source between dependencies, they just have to be
| ABI compatible.
| sneed_chucker wrote:
| If JavaScript (V8) and PyPy can be fast, then CPython can be
| fast too.
|
| It's just that the CPython developers and much of the Python
| community sat on their hands for 15 years and said stuff like
| "performance isn't a primary goal" and "speed doesn't really
| matter since most workloads are IO-bound anyway".
| jerf wrote:
| In this context, V8 and PyPy _aren 't_ fast. Or at least, not
| generally; they may actually do well on this task because
| pure number tasks are the only things they can sometimes, as
| long as you don't mess them up, get to compiled language-like
| performance. But they don't in general to compiled language
| performance, despite common belief to the contrary.
| Spivak wrote:
| Let's make this more concrete because assigning speed to
| languages is a fools errand. Python is doing _a lot_ more
| per line of code than compiled languages to enable its very
| flexible semantics. In cases where this flexibility is
| desired you won 't see much more performance in a compiled
| language as you'll have just implemented Python-like
| semantics on top of your compiled language-- GObject is a
| good example of this. More famously this is Greenspun's
| tenth rule.
|
| > Any sufficiently complicated C or Fortran program
| contains an ad hoc, informally-specified, bug-ridden, slow
| implementation of half of Common Lisp.
|
| But where this flexibility isn't required, which is a lot
| of performance sensitive number crunching code the cost of
| the flexibility bites you. You can't "turn it off" when you
| want control down to the instruction for a truly massive
| performance win. Which is why I think the model Python has
| of highly expressive and flexible language backed by high-
| performance compiled libraries is so successful.
|
| Python will never be number crunching or parsing with the
| best of them because it would require essentially a whole
| new language to express the low-level constraints but for
| high-level code that relies on Python's semantics you can
| get performance wins that can't be accomplished just by
| switching to a compiled language. We've just taken the
| "embedded scripting language" and made it the primary
| interface.
| adamc wrote:
| This gets into the whole "fast for what purpose"
| discussion. For many purposes, JavaScript is quite
| acceptably fast. But it isn't C or Rust.
| wormlord wrote:
| > On the other hand, a lot of these changes to try and speed up
| the base language are going to be highly disruptive. E.g.
| disabling the GIL will break tonnes of code, lots of
| compilation projects involve changes to the ABI, etc.
|
| Kind of related, the other day I was cursing like a sailor
| because I was having issues with some code I wrote that uses
| StrEnum not working with older versions of Python, and
| wondering why I did that, and trying to find the combination of
| packages that would work for the version of Python I needed--
| wondering why there was so much goddamn churn in this stupid
| [expletive] scripting language.
|
| But then I took a step back and realized that, actually, I
| should be glad about the churn because it means that there is a
| community of developers who care enough about the language to
| add new features and maintain this language so that I can just
| pipe PyQt and Numpy into each other and get paid.
|
| I don't have any argument, just trying to give an optimistic
| perspective.
| d0mine wrote:
| At least bugfix versions could have kept Enum behavior the
| same. Postponing breaking changes until the next minor
| version. Some Enum features work differently (incompatible)
| in Python 3.11.x versions.
| wormlord wrote:
| > Some Enum features work differently (incompatible) in
| Python 3.11.x versions.
|
| I wasn't aware of that, that's actually insane. It's odd to
| me that it took so long to get f-strings and Enums right in
| Python, I assumed those would be pretty easy language
| features to implement.
| yunohn wrote:
| > I guess getting loops in Python to run 5-10x faster will
| still save some people time
|
| I would recommend being less reductively dismissive, after
| claiming you "don't really have a dog in this race".
|
| Edit: Lots of recent changes have done way more than just loop
| unrolling JIT stuff.
| Capricorn2481 wrote:
| I don't really get this. They have already made Python faster
| in the past while maintaining the same semantics. Seems like a
| good goal to me.
| andai wrote:
| There was a discussion the other day about how Python devs
| apparently don't care enough for backwards compatibility. I
| pointed out that I've often gotten Python 2 code running on
| Python 3 by just changing print to print().
|
| But then a few hours later, I tried running a very small
| project I wrote _last year_ and it turned out that a bunch of
| my dependencies had changed their APIs. I 've had similar (and
| much worse) experiences trying to get older code with
| dependencies running.
|
| My meaning with this comment is, that if the average
| developer's reality is that backwards compatibility isn't
| really a thing anyway, then we are already paying for that
| downside so we might as well get some upside there, is my
| reasoning.
| almostgotcaught wrote:
| > I pointed out that I've often gotten Python 2 code running
| on Python 3 by just changing print to print().
|
| ...
|
| > I wrote last year and it turned out that a bunch of my
| dependencies had changed their APIs
|
| these two things have absolutely nothing to do with each
| other - couldn't be a more apples to oranges comparison if
| you tried
| andai wrote:
| I ran into both of these things in the same context, which
| is "the difficulty involved in getting old code working on
| the latest Python environment", which I understood as the
| context of this discussion.
| klysm wrote:
| So pin your deps? Language backwards compatibility and an API
| from some random package changing are completely distinct.
| epistasis wrote:
| Pinning deps is discouraged by years of Python practice.
| And going back to a an old project and finding versions
| that work, a year or more later, might be nigh on
| impossible.
|
| Last week I was trying to install snakemake via Conda, and
| couldn't find any way to satisfy dependencies at all, so
| it's not just pypi, and pip tends to be one of the more
| forgiving version dependency managers.
|
| It's not just Python, trying to get npm to load the
| requirements has stopped me from compiling about half of
| the projects I've tried to build (which is not a ton of
| projects). And CRAN in the R universe can have similar
| problems as projects age.
| klysm wrote:
| That doesn't match my experience at all. I have many
| Python projects going back years that all work fine with
| pinned dependencies
| vosper wrote:
| > Pinning deps is discouraged by years of Python
| practice.
|
| I'm not sure it is discouraged so much as just not what
| people did in Python-land for a long time. It's obviously
| the right thing to do, it's totally doable, it's just
| inertia and habit that might mean it isn't done.
| nicce wrote:
| It took me few days to get some old Jupyter Notebooks
| working. I had to find the correct older version of
| Jupyter, correct version of the every plugin/extension
| that notebook used and then I had to find the correct
| version of every dependency of these extensions. Only way
| to get it working was a bunch of pinned dependencies.
| adamc wrote:
| It's hard to comment on this without knowing more about the
| dependencies and when/how they changed their APIs. I would
| say if it was a major version change, that isn't too
| shocking. For a minor version change, it should be.
|
| Stuff that is actually included with Python tends to be more
| stable than random Pypi packages, though.
|
| NPM packages also sometimes change. That's the world.
| Timon3 wrote:
| The big difference is that npm will automatically (since
| 2017) save a version range to the project metadata, and
| will automatically create this metadata file if it doesn't
| exist. Same for other package managers in the Node world.
|
| I just installed Python 3.13 with pip 24.2, created a venv
| and installed a package - and nothing, no file was created
| and nothing was saved. Even if I touch requirements.txt and
| pyproject.toml, pip doesn't save anything about the
| package.
|
| This creates a massive gap in usability of projects by
| people not very familiar with the languages. Node-based
| projects sometimes have issues because dependencies changed
| without respecting semver, but Python projects often _can
| 't be installed_ and you have no idea why without spending
| lots of time looking through versions.
|
| Of course there are other package managers for Python that
| do this better, but pip is still the de-facto default and
| is often used in tutorials for new developers. Hopefully uv
| can improve things!
| andai wrote:
| Yeah, I guess I should have done a pip freeze to specify
| the versions in the requirements file. I wasn't thinking
| ahead.
|
| Turns out one dependency had 3 major releases in the span
| of a year! (Which basically confirms what I was saying,
| though I don't know how typical that is.)
| saurik wrote:
| The Python 2 to 3 thing was worse when they started: people
| who made the mistake of falling for the rhetoric to port to
| python3 early on had a much more difficult time as basic
| things like u"" were broken under an argument that they
| weren't needed anymore; over time the porting process got
| better as they acquiesced and unified the two languages a
| bit.
|
| I thereby kind of feel like this might have happened in the
| other direction: a ton of developers seem to have become
| demoralized by python3 and threw up their hands in defeat of
| "backwards compatibility isn't going to happen anyway", and
| now we live in a world with frozen dependencies running in
| virtual environments tied to specific copies of Python.
| jillesvangurp wrote:
| Why does python have to be slow? Improvements over the last few
| releases have made it quite a bit faster. So that kind of
| counters that a bit. Apparently it didn't need to be quite as
| slow all along. Other languages can be fast. So, why not
| python?
|
| I think with the GIL some people are overreacting: most python
| code is single threaded because of the GIL. So removing it
| doesn't actually break anything. The GIL was just making the
| use of threads kind of pointless. Removing it and making a lot
| of code thread safe benefits people who do want to use threads.
|
| It's very simple. Either you did not care about performance
| anyway and nothing really changes for you. You'd need to add
| threading to your project to see any changes. Unless you do
| that, there's no practical reason to disable the GIL for you.
| Or to re-enable that once disabled becomes the default. If your
| python project doesn't spawn threads now, it won't matter to
| you either way. Your code won't have deadlocking threads
| because it has only 1 thread and there was never anything to do
| for the GIL anyway. For code like that compatibility issues
| would be fairly minimal.
|
| If it does use threads, against most popular advise of that
| being quite pointless in python (because of the GIL), you might
| see some benefits and you might have to deal with some
| threading issues.
|
| I don't see why a lot of packages would break. At best some of
| them would be not thread safe and it's probably a good idea to
| mark the ones that are thread safe as such in some way. Some
| nice package management challenge there. And probably you'd
| want to know which packages you can safely use.
| eigenspace wrote:
| > Why does python have to be slow?
|
| Because the language's semantics promise that a bunch of
| insane stuff can happen at any time during the running of a
| program, including but not limited to the fields of classes
| changing at any time. Furthermore, they promise that their
| integers are aribtrary precision which are fundamentally
| slower to do operations with than fixed precision machine
| integers, etc.
|
| The list of stuff like this goes on and on and on. You
| fundamentally just cannot compile most python programs to
| efficient machine code without making (sometimes subtle)
| changes to its semantics.
|
| _________
|
| > I don't see why a lot of packages would break. At best some
| of them would be not thread safe and it's probably a good
| idea to mark the ones that are thread safe as such in some
| way. Some nice package management challenge there. And
| probably you'd want to know which packages you can safely
| use.
|
| They're not thread safe because it was semantically
| guaranteed to them that it was okay to write code that's not
| thread safe.
| adamc wrote:
| There are different definitions of slow, though. You might
| want arbitrary precision numbers but want it to be
| reasonable fast in that context.
|
| I don't agree that it is "insane stuff", but I agree that
| Python is not where you go if you need super fast
| execution. It can be a great solution for "hack together
| something in a day that is correct, but maybe not fast",
| though. There are a lot of situations where that is, by
| far, the preferred solution.
| eigenspace wrote:
| There are ways to design languages to be dynamic while
| still being friendly to optimizing compilers. Typically
| what you want to do is promise that various things are
| dynamic, but then static _within_ a single compilation
| context.
|
| julia is a great example of a highly dynamic language
| which is still able to compile complicated programs to
| C-equivalent machine code. An older (and less performant
| but still quite fast) example of such a language is
| Common Lisp.
|
| Python makes certain choices though that make this stuff
| pretty much impossible.
| adamc wrote:
| Not disputing it, but people don't pick Python because
| they need the fastest language, they pick it for friendly
| syntax and extensive and well-supported libraries. I
| loved Lisp, but none of the lisps have anything like
| Python's ecology. Julia, even less so.
|
| People don't pick languages for language features,
| mostly. They pick them for their ecosystems -- the
| quality of libraries, compiler/runtime support, the
| network of humans you can ask questions of, etc.
| eigenspace wrote:
| > loved Lisp, but none of the lisps have anything like
| Python's ecology. Julia, even less so.
|
| None of the lisps have anything close to julia's ecology
| in numerical computing at least. Can't really speak to
| other niches though.
|
| > People don't pick languages for language features,
| mostly. They pick them for their ecosystems -- the
| quality of libraries, compiler/runtime support, the
| network of humans you can ask questions of, etc.
|
| Sure. And that's why Python is both popular and slow.
| Jtsummers wrote:
| Common Lisp is probably not a good point of comparison.
| It offers comparable (if not more) dynamism to Python and
| still remains fast (for most implementations). You can
| redefine class definitions and function definitions on
| the fly in a Common Lisp program and other than the
| obvious overhead of invoking those things the whole
| system remains fast.
| eigenspace wrote:
| Common lisp is in fact a good point of comparison once
| you look at how it's fast. The trick with Common Lisp is
| that they made a foundation of stuff that can actually be
| optimized pretty well by a compiler, and made that stuff
| exempt from being changed on the fly (or in some cases,
| just made the the compiler assume that they won't change
| on the fly even if they do, resulting in seg-faults
| unless you recompile code and re-generate data after
| changing stuff).
|
| This is how Common Lisp people can claim that the
| language is both performant and flexible. The performant
| parts and the flexible parts are more disjoint than one
| might expect based on the way people talk about it.
|
| But anyways, Common Lisp _does_ manage to give a high
| degree of dynamism and performance to a point that it
| surely can be used for any of the dynamic stuff you 'd
| want to do in Python, while also giving the possibility
| of writing high performance code.
|
| Python did not do this, and so it'll be impossible for
| them to offer something like common lisp perf without
| breaking changes, or by just introducing a whole new set
| of alternatives to slow builtins like class, int, call,
| etc.
| Jtsummers wrote:
| > > Why does python have to be slow?
|
| > Because the language's semantics promise that a bunch
| of insane stuff can happen at any time during the running
| of a program, including but not limited to the fields of
| classes changing at any time.
|
| You originally claimed Python is slow because of its
| semantics and then compare later to CL. CL has a very
| similar degree of dynamism and remains fast. That's what
| I'm saying makes for a poor comparison.
|
| CL is a demonstration that Python, contrary to your
| initial claim, doesn't have to forfeit dynamism to become
| fast.
| eigenspace wrote:
| I think you're missing the point. Common Lisp is very
| dynamic yes, but it was designed in a very careful way to
| make sure that dynamism does not make an optimizing
| compiler impossible. That is not the case for Python.
|
| Not all dynamism is the same, even if the end result can
| feel the same. Python has a particularly difficult brand
| of dynamism to deal with.
| lispm wrote:
| > CL has a very similar degree of dynamism and remains
| fast.
|
| But not the dynamic parts remain "really" fast. Common
| Lisp introduced very early a lot of features to support
| optimizing compilers -> some of those reduce "dynamism".
| Code inlining (-> inline declarations), file compiler
| semantics, type declarations, optimization qualities
| (speed, compilation-speed, space, safety, debug, ...),
| stack allocation, tail call optimization, type
| inferencing, ...
| Archit3ch wrote:
| > You can redefine class definitions and function
| definitions on the fly in a Common Lisp program and other
| than the obvious overhead of invoking those things the
| whole system remains fast.
|
| You can also treat Julia as C and recompile vtables on
| the fly.
| rfoo wrote:
| > Python is never really going to be 'fast' no matter what is
| done to it because its semantics make most important
| optimizations impossible
|
| Scientific computing community have a bunch of code calling
| numpy or whatever stuff. They are pretty fast because, well,
| numpy isn't written in Python. However, there is a scalability
| issue: they can only drive so many threads (not 1, but not
| many) in a process due to GIL.
|
| Okay, you may ask, why not just use a lot of processes and
| message-passing? That's how historically people work around the
| GIL issue. However, you need to either swallow the cost of
| serializing data over and over again (pickle is quite slow,
| even it's not, it's wasting precious memory bandwidth), or do
| very complicated dance with shared memory.
|
| It's not for web app bois, who may just write TypeScript.
| eigenspace wrote:
| Numpy is not fast enough for actual performance sensitive
| scientific computing. Yes threading can help, but at the end
| of the day the single threaded perf isn't where it needs to
| be, and is held back too much by the python glue between
| Numpy calls. This makes interproceedural optimizations
| impossible.
|
| Accellerated sub-languages like Numba, Jax, Pytorch, etc. or
| just whole new languages are really the only way forward here
| unless massive semantic changes are made to Python.
| rfoo wrote:
| These "accelerated sub-languages" are still driven by,
| well, Python glue. That's why we need free-threading and
| faster Python. We want the glue to be faster because it's
| currently the most accessible glue to the community.
|
| In fact, Sam, the man behind free-threading, works on
| PyTorch. From my understanding he decided to explore nogil
| because GIL is holding DL trainings written in PyTorch
| back. Namely, the PyTorch DataLoader code itself and almost
| all data loading pipelines in real training codebases are
| hopeless bloody mess _just because_ all of the IPC /SHM
| nonsense.
| ggm wrote:
| You may be right. I personally think this work is net
| beneficial, and although I never expected to be in MP or
| threads, I now find doing a lot of DNS (processing end of day
| logs of 300m records per day, trying to farm them out over
| public DNS resolvers doing multiple RR checks per FQDN) that
| the MP efficiency is lower than threads, because of this
| serialisation cost. So, improving threading has shown me I
| could be 4-5x faster in this solution space, IFF I learn how to
| use the thread.lock to gatekeep updates on the shared
| structures.
|
| My alternative is to serialise in heavy processes and then
| incur a post process unification pass, because the cost of
| serialise send/receive deserialise to unify this stuff is too
| much. If somebody showed me how to use shm models to do this so
| it came back to the cost of threading.lock I'd do the IPC over
| a shared memory dict, but I can't find examples and now suspect
| multiprocessing in Python3 just doesn't do that (happy,
| delighted even to be proved wrong)
| nickpsecurity wrote:
| I spent some time looking into it. I believe it could be done
| with a source-to-source transpiler with zero-cost abstractions
| and some term rewriting. It's a lot of work.
|
| The real barrier my thought experiment hit were the extensions.
| Many uses of Python are glue around C extensions designed for
| the CPython interpreter. Accelerating "Python" might actually
| be accelerating Python, C, and hybrid code that's CPython-
| specific. Every solution seemed like more trouble than just
| rewriting those libraries to not be CPython-specific. Or maybe
| to work with the accelerators better.
|
| Most people are just using high-level C++ and Rust in the areas
| I was considering. If using Python, the slowdown of Python
| doesn't impact them much anyway since their execution time is
| mostly in the C code. I'm not sure if much will change.
| runeblaze wrote:
| For machine learning (un)fortunately, lots of the stack runs on
| Python. Lots of ceremony was done to circumvent GIL (e.g.
| PyTorch data loader). "Reasonable performance Python" I imagine
| is actually something in huge demand for lots of ML shops
| emgeee wrote:
| One area where this absolutely makes a difference is when
| embedding python. Like it or not Python is extreme popular in
| data/AI/ML so if you want to build an experience where users
| can deploy custom functions, removing the GIL allows you to
| more efficiently scale these workloads.
| pjmlp wrote:
| Since Python has become the new Lisp, the minimum is to have
| the performance tooling Common Lisp has had for several
| decades, in native code generation and multithreading (yes I
| know that in CL this is implementation specific).
| ijl wrote:
| Performance for python3.14t alpha 1 is more like 3.11 in what
| I've tested. Not good enough if Python doesn't meet your needs,
| but this comes after 3.12 and 3.13 have both performed worse for
| me.
|
| 3.13t doesn't seem to have been meant for any serious use. Bugs
| in gc and so on are reported, and not all fixes will be
| backported apparently. And 3.14t still has unavoidable crashes.
| Just too early.
| bastawhiz wrote:
| > 3.13t doesn't seem to have been meant for any serious use.
|
| I don't think anyone would suggest using it in production. The
| point was to put something usable out into the world so package
| maintainers could kick the tires and start working on building
| compatible versions. Now is exactly the time for weird bug
| reports! It's a thirty year old runtime and one of its oldest
| constraints is being removed!
| refdl wrote:
| _This is mostly because the free-threaded build requires the
| specializing adaptive interpreter to be disabled, thus clearly
| decreasing the performance of the other implementations. This
| overhead should be reduced in the 3.14 release where the
| specializing adaptive interpreter will be thread-safe and thus
| will be re-enabled._
|
| I do not think so. It is easy to find slowdowns compared to pre-
| JIT releases that eliminate that particular variable.
|
| It is easy to find 50% slowdowns with free-threading, which used
| to be censored until the core developers had to admit the issue
| due to a Sphinx report, after which the new GC was reverted.
|
| There is no guarantee that a thread-safe JIT will be faster
| either. The last four years have made many promises without
| really delivering. As usual in Python, people are kept in line
| with CoC threats and the official marketing is amplified.
| kmeisthax wrote:
| > people are kept in line with CoC threats
|
| Can you point to an example of someone claiming that a
| particular feature's performance claims were misleading, and
| then getting threatened with a ban or other sanctions for it,
| where they did not otherwise violate CoC?
| notatallshaw wrote:
| You seem to be conflating problems and different groups of
| people that aren't directly related.
|
| To clarify some different groups:
|
| * The faster-cpython project, headed by Guido and his team at
| Microsoft, is continuing fine, most of the low hanging fruit
| was accomplished by 3.11, further improvements were moved to
| medium term goals and they were delayed further by the free
| threaded project which broke assumptions that were made to
| optimize CPython, they have adapted but it has pushed big
| optimizations out to later released (think probably 3.15ish)
|
| * The free threaded project, initiated by Sam Gross at Meta, is
| continuing fine, it was never intended to be ready by 3.13, the
| fact there is even a build officially published is very fast
| progress. There isn't yet a plan to make it default, depending
| on the compatibility of the free threaded build it could be a
| quick transition or a 5+ year switch over.
|
| * The PSF, the Steering Council, and the CoC WG are all
| different groups that have different responsibilities and
| aren't typically involved in day-to-day choices of committing
| certain features.
|
| * The release manager is a core developer in charge of making
| the final choice on whether a particular feature is stable or
| not. It was the 3.13 release manager who decided to revert the
| new GC which was intended to generally improve performance for
| non-free threaded builds, which it may still do in a future
| release with sufficient fine tuning.
|
| Now, there are clearly communication issues in areas of the
| Python community, but there is also a lot of people getting on
| with great work and improvements and communicating fine.
| acdha wrote:
| > As usual in Python, people are kept in line with CoC threats
| and the official marketing is amplified.
|
| You'd need some serious evidence to back those claims up, and
| without it this seems like pure flamebait unrelated to the
| topic of this post.
| runjake wrote:
| If it were ever open sourced, I could see Mojo filling the
| performance niche for Python programmers. I'm hopeful because
| Lattner certainly has the track record, if he doesn't move on
| beforehand.
|
| https://en.wikipedia.org/wiki/Mojo_(programming_language)
| Decabytes wrote:
| I'm glad the Python community is focusing more on CPython's
| performance. Getting speed ups on existing code for free feels
| great. As much as I hate how slow Python is, I do think its
| popularity indicates it made the correct tradeoffs in regards to
| developer ease vs being fast enough.
|
| Learning it has only continued to be a huge benefit to my career,
| as it's used everywhere which underlies how important popularity
| of a language can be for developers when evaluating languages for
| career choices
___________________________________________________________________
(page generated 2024-11-05 23:00 UTC)