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

Intent to approve PEP 703: making the GIL optional

discuss.python.org

Post reply on HN
Print view View original

501–510 of 513 posts

Re: Intent to approve PEP 703: making the GIL optional

#501

Post by xmcqdpt2 »

sverhagen wrote: post #484
xmcqdpt2 wrote: post #368

Earlier quoted context omitted.

The new official Scala build tool / compiler front end (scala-cli) is amazing, https://scala-cli.virtuslab.org/ The thing that really struck me after years of python is how it lets you out dependencies directly in a comment on top of a script and it will download and run with them automatically, without poisoning any system settings. It's so simple!

Just curious: what makes it "official"?

It's going to be rolled out as the new standard Scala repl and compiler (instead of the current scalac which is a bit weak on features.)

Re: Intent to approve PEP 703: making the GIL optional

#502

Post by pjmlp »

weinzierl wrote: post #481
pjmlp wrote: post #309

Earlier quoted context omitted.

Like not everyone toy app isn't going to be the next FAANG, there are plenty of workloads where it hardly matters, while 30 years later it is still a mess in C and C++. And between C++ and Rust coroutines, still not sure which one I like less.

"And between C++ and Rust coroutines, still not sure which one I like less." I, myself, am not a Go guy, but I feel it has to be mentioned here. Go's approach might not be as universal as C++'s or Rust's but I think for a large number of use cases it makes sense.

Many that praise async/await in C#, kind of forget it took about 10 years to spread across all the layer of the language and runtime, since it was done via IL rewriting, it caused several issues with F# async tasks, due to the age of the ecosystem plenty of code isn't async/await friendly and needs to be wrapped into Task.Run() or similar.

There is a best practices guideline from one of the ASP.NET architects, https://github.com/davidfowl/AspNetCoreDiagnosticScenarios/b...

During last year they researched adding Go/Java's approach to .NET, but now it is too late. See the ASP.NET Q&A session at BUILD 2023.

Re: Intent to approve PEP 703: making the GIL optional

#503

Post by samus »

ShamelessC wrote: post #438
chx wrote: post #408

Earlier quoted context omitted.

Your comment has been nominated for the best typo in 2023. Let's hope the change is not this badly mercenary.

What?

Yes, in the first line. Only spotted it now, totally my bad. It's a very not nice word to say to women, and what it makes it worse is that it actually doesn't outright destroy the meaning of the sentence. I'm sure PEP-703's authors are not that desperate about enacting this change.

Re: Intent to approve PEP 703: making the GIL optional

#504

Post by commonlisp94 »

kerkeslager wrote: post #500
commonlisp94 wrote: post #498

Earlier quoted context omitted.

> Except that the threads share the exact same virtual address space, and processes do not, which makes the thread context switch faster That's what I said. But it's really not much. I'm afraid we will need numbers now to continue the conversation. If I measured would you be open to changing your opinion? Or are you committed to this topic, so that it would have no bearing?

Well, I don't know how you'd test that, but you should really consider testing the other half of the post you're responding to which you ignored, because that's much easier to test: Spin up and tear down a million pthreads in C, and see how long that takes and how much memory it takes. Then spin up and tear down a million processes in C and see your computer grind to a halt until you kill the process that is starting…

I just tried your tests on Debian. For some reason the threads one was failing at about 3000 (probably my config), so I bumped it down for both. Here are the results:

    $ gcc threads.c 
    $ time ./a.out 

   real 0m10.097s
   user 0m0.035s
   sys 0m0.239s

    $ gcc process.c 
    $ time ./a.out 
    real 0m10.168s
    user 0m0.579s
    sys  0m0.347s
Were you running on something besides linux, or not natively? Is this something that degrades with the large numbers?

Also, spawning is not context switching. That's the overhead that matters. But according to your own test, spawning in reasonable numbers will be about the same.

Re: Intent to approve PEP 703: making the GIL optional

#505

Post by gpderetta »

Dylan16807 wrote: post #350
lozenge wrote: post #342

Earlier quoted context omitted.

"Where is the need for recompilation?" https://docs.python.org/3/c-api/typeobj.html#c.PyObject.ob_r... The stable ABI lets extensions access the reference count of any object directly. I don't know why. Normally the functions Py_IncRef and Py_DecRef should be sufficient. Objects no longer have a single number as their reference count. Edit: In Python 3.2-3.9, the stable ABI included Py_INCREF, the C macro. https://do…

> Objects no longer have a single number as their reference count. Does that stay true once the GIL turns back on? > These can override tp_alloc field to use custom memory allocators when instances of the type are instantiated. The custom memory allocator needs to initialise the reference count to 1. I'm not following why this affects ABI compatibility, sorry. > So there needs to be a branch at the start of list.appe…

> I don't know about that. CPUs handle always-taken and never-taken branches very well.

and dynamic patching is also an option.

Re: Intent to approve PEP 703: making the GIL optional

#506

Post by ptx »

pjmlp wrote: post #502
weinzierl wrote: post #481

Earlier quoted context omitted.

"And between C++ and Rust coroutines, still not sure which one I like less." I, myself, am not a Go guy, but I feel it has to be mentioned here. Go's approach might not be as universal as C++'s or Rust's but I think for a large number of use cases it makes sense.

Many that praise async/await in C#, kind of forget it took about 10 years to spread across all the layer of the language and runtime, since it was done via IL rewriting, it caused several issues with F# async tasks, due to the age of the ecosystem plenty of code isn't async/await friendly and needs to be wrapped into Task.Run() or similar. There is a best practices guideline from one of the ASP.NET architects, https:…

This seems to be the relevant part of the Q&A: https://youtu.be/H5jI76Fq420?t=2396

Aside from being too late (already having two models and not wanting to add a third) they also mention that the Go/Java approach adds a performance penalty when calling native APIs.

Re: Intent to approve PEP 703: making the GIL optional

#507

Post by kerkeslager »

commonlisp94 wrote: post #504
kerkeslager wrote: post #500

Earlier quoted context omitted.

Well, I don't know how you'd test that, but you should really consider testing the other half of the post you're responding to which you ignored, because that's much easier to test: Spin up and tear down a million pthreads in C, and see how long that takes and how much memory it takes. Then spin up and tear down a million processes in C and see your computer grind to a halt until you kill the process that is starting…

I just tried your tests on Debian. For some reason the threads one was failing at about 3000 (probably my config), so I bumped it down for both. Here are the results: $ gcc threads.c $ time ./a.out real 0m10.097s user 0m0.035s sys 0m0.239s $ gcc process.c $ time ./a.out real 0m10.168s user 0m0.579s sys 0m0.347s Were you running on something besides linux, or not natively? Is this something that degrades with the larg…

> Were you running on something besides linux, or not natively?

Running on MacOS, but I've run this in Linux.

> Is this something that degrades with the large numbers?

The concern here is memory--once you push into pagefile your processes will become extremely slow.

> Also, spawning is not context switching.

Thank you obviousman.

> That's the overhead that matters.

Why do you think you know every use case? You don't. There are tons of use cases where having to be concerned about creating and destroying threads places a large burden on the developer.

> But according to your own test, spawning in reasonable numbers will be about the same.

You didn't run my test.

Running 3000 processes is a few orders of magnitude less than running 1000000, and you don't get to determine what "reasonable" is for every application that exists.

Re: Intent to approve PEP 703: making the GIL optional

#508

Post by chippiewill »

n2d4 wrote: post #66
slt2021 wrote: post #54

Naiive question: Who needs No-GIL when we have asyncio and multiprocessing packages ? never ever had a problem with GIL in python, always found a workaround just by spinning up ThreadPool or ProcessPool, and used async libraries when needed. is there any use case of No-GIL which is not solved by multiprocessing ? I thought Single threaded execution without overhead for concurrency primitives is the best way to high p…

It's only about performance. asyncio is still inherently single-threaded, and hence also single core. multiprocessing is multi-core and hence better for performance, but each process is relatively heavy and there's additional overhead to shared memory. GIL multi-threading is both single-core and difficult to use correctly. No-GIL multi-threading is multi-core, though difficult to use. I don't know the Python implemen…

> asyncio is still inherently single-threaded, and hence also single core.

IIRC some of the proposals around removing the GIL in the past have actually suggested that the asyncio paradigm could become multithreaded for parallelism.

Re: Intent to approve PEP 703: making the GIL optional

#509

Post by commonlisp94 »

kerkeslager wrote: post #507
commonlisp94 wrote: post #504

Earlier quoted context omitted.

I just tried your tests on Debian. For some reason the threads one was failing at about 3000 (probably my config), so I bumped it down for both. Here are the results: $ gcc threads.c $ time ./a.out real 0m10.097s user 0m0.035s sys 0m0.239s $ gcc process.c $ time ./a.out real 0m10.168s user 0m0.579s sys 0m0.347s Were you running on something besides linux, or not natively? Is this something that degrades with the larg…

> Were you running on something besides linux, or not natively? Running on MacOS, but I've run this in Linux. > Is this something that degrades with the large numbers? The concern here is memory--once you push into pagefile your processes will become extremely slow. > Also, spawning is not context switching. Thank you obviousman. > That's the overhead that matters. Why do you think you know every use case? You don't.…

It's your own test, I don't need see why you need to respond in this manner.

> Running 3000 processes is a few orders of magnitude less than running 1000000

I didn't decide on the limit, my OS did. So they must think it's unreasonable.

> Running on MacOS, but I've run this in Linux.

Well your test works fine on linux. MacOS is not designed to run large multi-process server loads. Linux has specifically optimized forking and context switching for processes.

> Why do you think you know every use case?

Why do you think you can't handle most cases by using processes? The goal isn't for a tool to handle every use case, it's to handle a specified set of use cases well.

Python itself doesn't work for every use case.

Looks like we are safe to ignore overhead of launching processes for programs with fewer than 3000 threads.

> Thank you obviousman.

I wanted to compare context switch, you decided to measure something else. I am pleasantly surprised anyway.

Re: Intent to approve PEP 703: making the GIL optional

#510

Post by kerkeslager »

commonlisp94 wrote: post #509
kerkeslager wrote: post #507

Earlier quoted context omitted.

> Were you running on something besides linux, or not natively? Running on MacOS, but I've run this in Linux. > Is this something that degrades with the large numbers? The concern here is memory--once you push into pagefile your processes will become extremely slow. > Also, spawning is not context switching. Thank you obviousman. > That's the overhead that matters. Why do you think you know every use case? You don't.…

It's your own test, I don't need see why you need to respond in this manner. > Running 3000 processes is a few orders of magnitude less than running 1000000 I didn't decide on the limit, my OS did. So they must think it's unreasonable. > Running on MacOS, but I've run this in Linux. Well your test works fine on linux. MacOS is not designed to run large multi-process server loads. Linux has specifically optimized fork…

> I didn't decide on the limit, my OS did. So they must think it's unreasonable.

> Well your test works fine on linux. MacOS is not designed to run large multi-process server loads. Linux has specifically optimized forking and context switching for processes.

Oh JFC, stop wildly speculating and pretending it's the truth. The test was a million threads/processes, and you ran 3000. By your own description you didn't run the test, period. I just ran it on Debian on a VPS and, you know, it did exactly what I said it was going to do, because gosh, this isn't the first time I've run this test on Linux.

And you seriously want to attribute this to Linux having optimized forking and context switching as if you have any idea what that means? Please do tell, which optimizations did they apply that somehow they've hidden from BSD and Apple?

Given your propensity to make things up when you don't know something, I'm beginning to think whatever problem you ran into with a million threads was fixable and you just didn't know how to, so you made up a new straw man test to try and win an argument. Have you measured the memory usage at 3000 yet, or are you still ignoring any part of reality that isn't convenient for your argument?

> Why do you think you can't handle most cases by using processes?

Where did I say that? Unlike you, I don't make generalizations about "most use cases" because I don't pretend to know what everyone in the world is doing.

> The goal isn't for a tool to handle every use case, it's to handle a specified set of use cases well.

What do you mean, "the goal"? You speak for every possible goal anyone using Python could possibly have now?

> I wanted to compare context switch, you decided to measure something else.

Then do it! I'd be interested to see the results, and even more interested to see how you tested it.

In any case, you can't just ignore tests you don't want to do or apparently aren't capable of. Being able to run a lot of threads can be extremely useful for networking applications, which is why I care. You don't get to decide my use case is "unreasonable" because you apparently can't compile a program that does a stripped down version of it.

That is to say, even if context switching is faster in processes than in threads, that doesn't mean there's no use to threads, because there are use cases where spinning up and tearing down is more common than context switching.

> I am pleasantly surprised anyway.

Ignorance is bliss, I suppose.

Post reply on HN