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

The first year of free-threaded Python

labs.quansight.org

Post reply on HN
Print view View original

241–250 of 302 posts

Re: The first year of free-threaded Python

#241

Post by kstrauser »

Izkata wrote: post #237
kstrauser wrote: post #226

Earlier quoted context omitted.

I really wish Python had a way to annotate things you don't care about cleaning up. I don't know what the API would look like, but I imagine something like: l = list(cleanup=False) for i in range(1_000_000_000): l.append(i) telling the runtime that we don't need to individually GC each of those tiny objects and just let the OS's process model free the whole thing at once. Sure, close TCP connections before you kill t…

There's already a global: import gc gc.disable() So I imagine putting more in there to remove objects from the tracking.

That can go a long way, so long as you remember to manually GC the handful of things you do care about.

Re: The first year of free-threaded Python

#242

Post by kstrauser »

zahlman wrote: post #229
kstrauser wrote: post #76

Earlier quoted context omitted.

That’s not what the phrase implies. If you have a C program from 1982, you can still compile it on a 1982 operating system and toolchain and it’ll work just as before. But if you tried to compile it on today’s libc, making today’s syscalls… good luck with that. Software “rots” in the sense that it has to be updated to run on today’s systems. They’re a moving target. You can still run HyperCard on an emulator, but goo…

> You can still run HyperCard on an emulator, but good luck running it unmodded on a Mac you buy today. I grew up with HyperCard, so I had a moment of sadness here.

We all have our own personal HyperCard.

Re: The first year of free-threaded Python

#243

Post by seabrookmx »

AlexanderDhoore wrote: post #2

Am I the only one who sort of fears the day when Python loses the GIL? I don't think Python developers know what they’re asking for. I don't really trust complex multithreaded code in any language. Python, with its dynamic nature, I trust least of all.

While it certainly has its rough edges, I'm a big asyncio user. So I'll be over here happily writing concurrent python that's single threaded, ie. pretending my Python is nodejs.

For the web/network workloads most of us write, I'd highly recommend this.

Re: The first year of free-threaded Python

#244

Post by celeritascelery »

foresto wrote: post #166
celeritascelery wrote: post #98

Earlier quoted context omitted.

> That's the trade-off. Personally I think a single digit percentage slow-down of single-threaded code worth it. Maybe. I would expect that 99% of python code going forward will still be single threaded. You just don’t need that extra complexity for most code. So I would expect that python code as a whole will have worse performance, even though a handful of applications will get faster.

As I recall, CPython has also been getting speed-ups lately, which ought to make up for the minor single-threaded performance loss introduced by free threading. With that in mind, the recent changes seem like an overall win to me.

It’s not either/or. The CPython speedups would be even better with the single threaded interpreter.

Re: The first year of free-threaded Python

#245

Post by charleshn »

charleshn wrote: post #223
crackez wrote: post #190

Earlier quoted context omitted.

Fork on Linux should use copy-on-write vmpages now, so if you fork inside python it should be cheap. If you launch a new Python process from let's say the shell, and it's already in the buffer cache, then you should only have to pay the startup CPU cost of the interpreter, since the IO should be satisfied from buffer cache...

> Fork on Linux should use copy-on-write vmpages now, so if you fork inside python it should be cheap. No, that's exactly the point I'm making, copying PTEs is not cheap on a large address space, woth many VMAs. You can run a simple python script allocating a large list and see how it affects fork time.

See e.g. https://www.alibabacloud.com/blog/async-fork-mitigating-quer...

Re: The first year of free-threaded Python

#246

Post by zahlman »

kstrauser wrote: post #238
zahlman wrote: post #233

Earlier quoted context omitted.

You'd presumably need to do something involving weakrefs, since it would be really bad if you told Python that the elements can be GCd at all (never mind whether it can be done all at once) but someone else had a reference. Or completely rearchitect the language to have a model of automatic (in the C sense) allocation. I can't see that ever happening.

I don't think either of those are true. I'm not arguing against cleaning up objects during the normal runtime. What I'd like is something that would avoid GC'ing objects one-at-a-time at program shutdown. I've had cases where it took Python like 30 seconds to exit after I'd slurped a large CSV with a zillion rows into RAM. At that time, I'd dreamed of a way to tell Python not to bother free()ing any of that, just exi…

Ah.

I imagine the problem is that `__del__` could be monkeypatched, so Python doesn't strictly know what needs custom finalization until that moment.

But if you have a concrete proposal, it's likely worth shopping around at https://discuss.python.org/c/ideas/6 or https://github.com/python/cpython/issues/ .

Re: The first year of free-threaded Python

#248

Post by kstrauser »

zahlman wrote: post #246
kstrauser wrote: post #238

Earlier quoted context omitted.

I don't think either of those are true. I'm not arguing against cleaning up objects during the normal runtime. What I'd like is something that would avoid GC'ing objects one-at-a-time at program shutdown. I've had cases where it took Python like 30 seconds to exit after I'd slurped a large CSV with a zillion rows into RAM. At that time, I'd dreamed of a way to tell Python not to bother free()ing any of that, just exi…

Ah. I imagine the problem is that `__del__` could be monkeypatched, so Python doesn't strictly know what needs custom finalization until that moment. But if you have a concrete proposal, it's likely worth shopping around at https://discuss.python.org/c/ideas/6 or https://github.com/python/cpython/issues/ .

I might do that. It’s nothing I’ve thought about in depth, just an occasionally recurring idea that bugs me every now and then.

Re: The first year of free-threaded Python

#249

Post by ori_b »

kstrauser wrote: post #224
ori_b wrote: post #204

Earlier quoted context omitted.

As another example: I run https://shithub.us with shell scripts, serving a terabyte or so of data monthly (mostly due to AI crawlers that I can't be arsed to block). I'm launching between 15 and 3000 processes per request. While Plan 9 is about 10x faster at spawning processes than Linux, it's telling that 3000 C processes launching in a shell is about as fast as one python interpreter.

The interpreter itself is pretty quick: ᐅ time echo "print('hi'); exit()" | python hi ________________________________________________________ Executed in 21.48 millis fish external usr time 16.35 millis 146.00 micros 16.20 millis sys time 4.49 millis 593.00 micros 3.89 millis

My machine is marginally faster for that; I get about 17ms doing that with python, without the print:

    time echo "exit()" | python3

    real    0m0.017s
    user    0m0.014s
    sys     0m0.003s
That's... still pretty slow. Here's a C program, run 100 times:

    range=`seq 100`
    time for i in $range; do ./a.out; done

    real    0m0.038s
    user    0m0.024s
    sys     0m0.016s
And finally, for comparison on Plan 9:

   range=`{seq 2000}
   time rc -c 'for(s in $range){ ./6.nop }'

   0.01u 0.09s 0.16r   rc -c for(s in $range){ ./6.nop }
the C program used was simply:

   int main(void) { return 0; }
Of course, the more real work you do in the program, the less it matters -- but there's a hell of a lot you can do in the time it takes Python to launch.

Re: The first year of free-threaded Python

#250

Post by kragen »

duped wrote: post #236
kstrauser wrote: post #226

Earlier quoted context omitted.

I really wish Python had a way to annotate things you don't care about cleaning up. I don't know what the API would look like, but I imagine something like: l = list(cleanup=False) for i in range(1_000_000_000): l.append(i) telling the runtime that we don't need to individually GC each of those tiny objects and just let the OS's process model free the whole thing at once. Sure, close TCP connections before you kill t…

Tbh if you're optimizing python code you've already lost

On a 64-core machine, Python code that uses all the cores will be modestly faster than single-threaded C, even if all the inner loops are in Python. If you can move the inner loops to C, for example with Numpy, you can do much better still. (Python is still harder to get right than something like C or OCaml, of course, especially for larger programs, but often the smaller amount of code and quicker feedback loop can compensate for that.)
Post reply on HN