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

Let's Remove the Global Interpreter Lock

morepypy.blogspot.com

Post reply on HN
Print view View original

91–100 of 326 posts

Re: Let's Remove the Global Interpreter Lock

#91

Post by dom0 »

colesbury wrote: post #51
dec0dedab0de wrote: post #12

Could someone who really wants to get rid of the GIL explain the appeal? As far as I understand, the only time it would be useful is when you have an application that is 1. Big enough to need concurrency 2. Not big enough to require multiple boxes. 3. Running in a situation that can not spare the resources for multiprocessing. 4. You want to share memory instead of designing your workflow to handle messages or workin…

Your criteria 2, 3, and 4 doesn't make much sense to me. We often have workloads that require multiple boxes, but we still want to make effective use of each box. Common server hardware has dozens of cores, which requires a lot of parallelism to fully utilize. The GIL hinders that, even when most of the work doesn't hold the GIL (see Amdahl's law) Python multiprocessing doesn't work well with a lot of external librar…

> (see Amdahl's law)

Amdahl's law bears little relevance to throughput computing (i.e. most servers).

> (It's also buggy, has internal race conditions, and easily leaks resources.)

There is also at least one memory corruption bug in multiprocessing (linked a few months back by a fellow HN reader).

Re: Let's Remove the Global Interpreter Lock

#92

Post by dom0 »

PrimHelios wrote: post #64
colesbury wrote: post #51

Earlier quoted context omitted.

Your criteria 2, 3, and 4 doesn't make much sense to me. We often have workloads that require multiple boxes, but we still want to make effective use of each box. Common server hardware has dozens of cores, which requires a lot of parallelism to fully utilize. The GIL hinders that, even when most of the work doesn't hold the GIL (see Amdahl's law) Python multiprocessing doesn't work well with a lot of external librar…

CPython doesn't have any reservations about breaking the Python API between minor versions, so why care about the C API? I get where you're coming from, but they've already shown they don't care much for compatibility, so I don't see why that's a big obstacle.

Removing the GIL (in a non-braindead way) likely entails breaking all existing code using the C API. PyPy could do so without breaking cpyext, by maintaining the illusion of a GIL whenever control passes to cpyext.

Re: Let's Remove the Global Interpreter Lock

#93

Post by bobwaycott »

ant6n wrote: post #18
dec0dedab0de wrote: post #12

Could someone who really wants to get rid of the GIL explain the appeal? As far as I understand, the only time it would be useful is when you have an application that is 1. Big enough to need concurrency 2. Not big enough to require multiple boxes. 3. Running in a situation that can not spare the resources for multiprocessing. 4. You want to share memory instead of designing your workflow to handle messages or workin…

Using multiprocessing is a pain to use, and it's slow.

If you’re looking for simple threaded multiprocessing, it’s not that hard/painful:

    from multiprocessing.dummy import Pool
    
    pool = Pool(num_threads)
    result = pool.map(your_func, your_objects)
    pool.close()
    pool.join()
Improve and/or complicate things from there.

Re: Let's Remove the Global Interpreter Lock

#94

Post by dweekly »

dmix wrote: post #89
sandGorgon wrote: post #70

This is a PERFECT usecase for Kickstarter. It makes me sad that this is a blog post that made it number 1 on HN with vast readership with open pursestrings.. yet there is not a campaign fundraising link. Use Kickstarter or Plasso to sell a pypy pro license - its so much easier for companies to pay invoices than to donate. If nothing else, I would pay for an official conda pypy package which works seamlessly with pand…

> yet there is not a campaign fundraising link. Did you read the article? They said in the article they aren't asking for individual donations at the moment: >> we would like to judge the interest of the community and the commercial partners to make it happen (we are not looking for individual donations at this point) Plus I'm sure they will consider using Kickstarter when the time comes.

Cash is one objective way to discern interest.

Re: Let's Remove the Global Interpreter Lock

#95

Post by eddigo »

btown wrote: post #22
dec0dedab0de wrote: post #12

Could someone who really wants to get rid of the GIL explain the appeal? As far as I understand, the only time it would be useful is when you have an application that is 1. Big enough to need concurrency 2. Not big enough to require multiple boxes. 3. Running in a situation that can not spare the resources for multiprocessing. 4. You want to share memory instead of designing your workflow to handle messages or workin…

Say you're running CPU-bound workers that need to load significant data into RAM - say, a machine learning or NLP model. The most cost-effective theoretical approach would be to have that in shared memory, so you're not paying for that RAM multiple times in order to fully utilize all cores. Even if you need multiple boxes, the cost savings per core would be substantial. My understanding is that multiprocessing makes…

I've run into this exact situation. I have a C extension that does some specialized vector operations. These functions use some language models that can be fairly large. The language models are fixed throughout the calculations, and the other data required can be segmented so the operations can happen in parallel. Also, the language model and data can be handled as read-only.

Trying to do this with the multiprocessing module is not terribly straightforward.

Re: Let's Remove the Global Interpreter Lock

#96

Post by aidenn0 »

myusernameisok wrote: post #8
taf2 wrote: post #4

Earlier quoted context omitted.

If I understand correctly the issue in Ruby is the existing C extensions that have been written to assume the lock exists...

It's the same issue with Python. AFAIK there are a number of Python libraries that are not thread-safe, and the GIL prevents them from being an issue.

I thought the GIL was not held during execution of foreign code in python (at least that was one point given for why the GIL wasn't a big deal in practice).

Re: Let's Remove the Global Interpreter Lock

#97

Post by crb002 »

Having ported Ruby to IBM's Blue Gene/L my advice is to forget about the GIL. Run one Python process per core. Use something like MPI2 for message passing communication. Ruthlessly eliminate bloat code from production binaries and statically link all the things.

Re: Let's Remove the Global Interpreter Lock

#98

Post by twoodfin »

"It mostly works for simple programs, but probably segfaults on anything complicated" is not a promising beginning. Starting with race condition chaos and trying to patch your way out of it with "strategic" locking

a) Inspires much less confidence than starting with a known-correct locking model (the degenerate case being a GIL) and preserving it while improving available concurrency.

and

b) Seems at least 50/50 to end up without much in the way of tangible scalability gains once enough locking has been added to reduce the rate of crashes and data corruption to an acceptable (?!) degree. At least that was my takeaway from all the challenges Larry Hastings has documented while working on the gilectomy. Sure, they don't have to worry about locking around reference counting, but it's not like writing a (concurrent?) GC operating against concurrently executing threads isn't a significant design challenge itself with many tradeoffs to make.

Re: Let's Remove the Global Interpreter Lock

#99

Post by masklinn »

taeric wrote: post #90
rguillebert wrote: post #79

Earlier quoted context omitted.

It's not the PyPy developers' job to make every Python library threadsafe, people writing libraries will have to make their code threadsafe, like in every other language.

There is a clear difference here, though. Making a change that could lead to poorly written libraries now being broken is clearly the fault of the change. Userspace for these libraries is defined by how it is, not how it was intended. (And really, was it intended to be dangerous in this way?)

> There is a clear difference here, though. Making a change that could lead to poorly written libraries now being broken is clearly the fault of the change.

No, these libraries are already semantically broken in the same way e.g. libraries which didn't properly close their files and assumed the CPython refcounting GC would wipe there asses were broken.

They're already broken under two non-GIL'd implementations.

Re: Let's Remove the Global Interpreter Lock

#100

Post by dom0 »

btown wrote: post #22
dec0dedab0de wrote: post #12

Could someone who really wants to get rid of the GIL explain the appeal? As far as I understand, the only time it would be useful is when you have an application that is 1. Big enough to need concurrency 2. Not big enough to require multiple boxes. 3. Running in a situation that can not spare the resources for multiprocessing. 4. You want to share memory instead of designing your workflow to handle messages or workin…

Say you're running CPU-bound workers that need to load significant data into RAM - say, a machine learning or NLP model. The most cost-effective theoretical approach would be to have that in shared memory, so you're not paying for that RAM multiple times in order to fully utilize all cores. Even if you need multiple boxes, the cost savings per core would be substantial. My understanding is that multiprocessing makes…

Unless your model actually consists of a large number of Python objects (and not a handful of PyObjects referencing something like a np array), there isn't really anything blocking you from doing so. You can have a master process map the blob of static data into a block of shared memory that's mapped by the secondary processes; ctypeslib lets you access it as a numpy array again.
Post reply on HN