Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reverting the incremental GC in Python 3.14 and 3.15

discuss.python.org

Post reply on HN
Print view View original

101–110 of 134 posts

Re: Reverting the incremental GC in Python 3.14 and 3.15

#101

Post by pjmlp »

elch wrote: post #92
pjmlp wrote: post #86

Earlier quoted context omitted.

> The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt. -- Rob Pike

Any reference to the biggest issues with Go in your opinion, and what are you comparing it to?

Basically complete disregard for the history of programming languages and learnt lessons.

Go fits well close to Oberon released in 1987, or Limbo in 1995, when exceptions and generics were still esoteric features.

Instead they had to reach out to Phil Wadler to help them, as he did previously with Java almost a decade earlier, panic/recover is clunky way to do exceptions, instead of doing enumerations like Pascal in 1976, it needs a a iota/const code pattern, hardcoded urls for source repos, if err all over the place like last century programming, many errors are plain strings, ah and nil interfaces what a great gotcha.

Re: Reverting the incremental GC in Python 3.14 and 3.15

#102

Post by elch »

pjmlp wrote: post #101
elch wrote: post #92

Earlier quoted context omitted.

Any reference to the biggest issues with Go in your opinion, and what are you comparing it to?

Basically complete disregard for the history of programming languages and learnt lessons. Go fits well close to Oberon released in 1987, or Limbo in 1995, when exceptions and generics were still esoteric features. Instead they had to reach out to Phil Wadler to help them, as he did previously with Java almost a decade earlier, panic/recover is clunky way to do exceptions, instead of doing enumerations like Pascal in…

Thanks!

Re: Reverting the incremental GC in Python 3.14 and 3.15

#103

Post by coldtea »

refulgentis wrote: post #79
coldtea wrote: post #71

Earlier quoted context omitted.

> As far as I know, java has 7 GC implementations, none of which are perfect, all of which have drawbacks Compared to Python's, all of them are beyond perfect. And 99.9% of the time you don't even need to use anything but the default.

> Compared to Python's, all of them are beyond perfect. I somehow understand the situation less after reading this. Is Python's GC bad , or are there cyclic reference issues? Is it possible to detect cyclic references perfectly? What does beyond perfect mean? If we have 7 and 0.1% of the time you need one of the 6 that is non-default, how do we choose? Is the understated version of "Compared to Python's, all of them…

>Is Python's GC bad, or are there cyclic reference issues?

Both can be true. The first can even be wholly or partly due to the second.

On addition, the way it does it via RC causes fragmentation, poor locality for caches, and general slowness for mass allocations. And it's one-size-fits-all.

Java has a much larger selection to pick to finetune specific use cases, which each being far greater for that use case. And the default no-need-to-think one (G1 iirc), is already faster and better than Python's.

Re: Reverting the incremental GC in Python 3.14 and 3.15

#105

Post by JackSlateur »

coldtea wrote: post #103
refulgentis wrote: post #79

Earlier quoted context omitted.

> Compared to Python's, all of them are beyond perfect. I somehow understand the situation less after reading this. Is Python's GC bad , or are there cyclic reference issues? Is it possible to detect cyclic references perfectly? What does beyond perfect mean? If we have 7 and 0.1% of the time you need one of the 6 that is non-default, how do we choose? Is the understated version of "Compared to Python's, all of them…

> Is Python's GC bad, or are there cyclic reference issues? Both can be true. The first can even be wholly or partly due to the second. On addition, the way it does it via RC causes fragmentation, poor locality for caches, and general slowness for mass allocations. And it's one-size-fits-all. Java has a much larger selection to pick to finetune specific use cases, which each being far greater for that use case. And t…

Are you not confusing GC (freeing memory) with the memory allocator ?

Memory allocator: tcmalloc, jemalloc, they are concerned with fetching (and releasing) pages of memory from the OS and allocating objects for the program

GC is only responsible for saying to the memory allocator "this object is no longer used"

(please stay focused on java)

Re: Reverting the incremental GC in Python 3.14 and 3.15

#106

Post by shay_ker »

rtpg wrote: post #78
athoscouto wrote: post #23

We've been impacted by this. I migrated our services to Python 3.14 so we could attach profilers during runtime. A couple of services looked like they had a memory leak. Memory was continuously increasing over time. Thanks to Python 3.14, we were able to use memray to understand what was going on. Those services were recreating HTTP clients (aiohttp) for every inbound request, and memory allocated by the downstream S…

We've been chasing down similar aiohttp client creation issues (liked to ...aiobotocore usage) for months now. It's annoying that somehow talking to S3 etc requires so much churn. We have been trying to cache session objects and the like but clearly are still missing something. Chasing this down has also made me realize how little Python libs use `weakref`, and just will build up so many circular references. The othe…

It's really fascinating to read this, since I've encountered similar memory issues in other languages (ruby, go, etc.). Debugging these issues is a pain.

Is there a way to make all this much easier to debug and to prevent memory issues in the first place? Is the abstraction level not quite right?

Re: Reverting the incremental GC in Python 3.14 and 3.15

#107

Post by mirashii »

bmitc wrote: post #93
davidkwast wrote: post #2

"Python 3.14 shipped with a new incremental garbage collector. However, we’ve had a number of reports of significant memory pressure in production environments. We’ve decided to revert it in both 3.14 and 3.15, and go back to the generational GC from 3.13." Sounds the right move for me

Why are people still building systems on top of a language that continually undergoes fundamental changes nearly 40 years after release? Is this not the strongest indication that this language is not well designed, it is unstable, and encounters many issues that flat out don't exist in other high level languages?

What language that is actually used 40 years after release isn't undergoing big, fundamental changes?

Java? Nope, you're getting a fundamental change in Valhalla C++? Nope, new language edition every few years with fundamental changes C? C23 has a number of fairly fundamental changes, expect more in the next language revision

I think your sense of causality is backwards here. These languages are getting fundamental changes because they're being widely used. That is what motivates and drives the change. Languages with no users don't need to change.

Re: Reverting the incremental GC in Python 3.14 and 3.15

#108

Post by NooneAtAll3 »

metalliqaz wrote: post #35
NooneAtAll3 wrote: post #3

I'm genuinely surprised that python change was even possible without PEP

It's not a change to the language, it's a change to the cpython runtime

problem is that Python is so centralized, CPython is essentially a "reference implementation"

Re: Reverting the incremental GC in Python 3.14 and 3.15

#109

Post by mandarax8 »

JackSlateur wrote: post #105
coldtea wrote: post #103

Earlier quoted context omitted.

> Is Python's GC bad, or are there cyclic reference issues? Both can be true. The first can even be wholly or partly due to the second. On addition, the way it does it via RC causes fragmentation, poor locality for caches, and general slowness for mass allocations. And it's one-size-fits-all. Java has a much larger selection to pick to finetune specific use cases, which each being far greater for that use case. And t…

Are you not confusing GC (freeing memory) with the memory allocator ? Memory allocator: tcmalloc, jemalloc, they are concerned with fetching (and releasing) pages of memory from the OS and allocating objects for the program GC is only responsible for saying to the memory allocator "this object is no longer used" (please stay focused on java)

Please read up some more about Java and GCs. Memory allocation and GC are heavily intertwined.

Re: Reverting the incremental GC in Python 3.14 and 3.15

#110

Post by jerf »

LtWorf wrote: post #91
zozbot234 wrote: post #45

Earlier quoted context omitted.

Why not just use Go? It has a proper concurrent, non-moving GC that, AIUI, has not been associated with sudden memory spikes.

It's a tradeoff. Go programs are extremely slow at starting up for example.

A do nothing C program (int main() { return; }):

    $ time ./a.out

    real    0m0.002s
    user    0m0.000s
    sys     0m0.002s
A do-nothing Go program:

    $ time ./tmp

    real    0m0.002s
    user    0m0.000s
    sys     0m0.003s
I don't believe Go has any optimizations to not start its runtime if it isn't necessary, but when I added spawning a goroutine that immediately blocks on a channel read that will never come the numbers didn't change. That doesn't really time the runtime. Probably the program terminated before the goroutine was scheduled to run anything. It just makes it so there definitely wasn't an early exit because the compiler or the runtime "realized" it didn't need to start the runtime.

I'm sure the Go program is somewhat slower to start and end than C, and that we're running into the limits of how quickly processes can be spawned and other timing overhead which is obscuring the difference. However for practical purposes, "it starts up in less than the overhead for starting a process in the shell" is the same speed for most purposes.

Not even a "do nothing" Python program, no Python program at all:

    $ time python3 -c 1

    real    0m0.012s
    user    0m0.008s
    sys     0m0.004s
If you had a Go program that was slow to start up, it was your program, not Go. By contrast, Python, and the dynamic scripting languages in general, can be quite slow to start up, just in the reading and compiling of the code. (Even .pyc files, IIRC, take processing, just less processing than Python source code... it's still nowhere near "memory map it in and go" as it is for statically-compiled languages.)
Post reply on HN