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

271–280 of 326 posts

Re: Let's Remove the Global Interpreter Lock

#271

Post by jzwinck »

throwaway613834 wrote: post #254
jzwinck wrote: post #253

Earlier quoted context omitted.

While a lot of NumPy is C and Fortran, Pandas is mostly pure Python and some Cython. And mostly it does not release the GIL. You often end up having to implement your own C extensions or use Numba for the core of your processing. Even with BLAS enabled, NumPy has almost zero intrinsic parallelism, np.dot() being the notable exception which releases the GIL and uses multicore by itself.

> Even with BLAS enabled, NumPy has almost zero intrinsic parallelism, np.dot() being the notable exception which releases the GIL and uses multicore by itself. Is there any sort of list (comprehensive or otherwise) that denotes which NumPy functions are parallelism-friendly? I mean this whether it's in terms of releasing the GIL, in terms of SIMD support, or in terms of being multi-core.

Why are you asking this using a throwaway?

np.dot() is multicore. np.load () (and family) releases the GIL. SIMD mostly depends on the build system, so if you want it you might need to build NumPy from source.

https://stackoverflow.com/questions/24022723/where-can-i-fin...

Re: Let's Remove the Global Interpreter Lock

#272

Post by bhntr3 »

riri-au wrote: post #252
eslaught wrote: post #161

The comments here are missing a massive use case: shared memory. Shared memory isn't just about programmer convenience. It's about using a machine's memory resources more effectively. Yes, shared memory is available in multi-processing, but it doesn't necessarily interact well with existing codes. I've been working on adding Python support to Legion [1], a task-based runtime system for HPC. Legion wants to manage sha…

Agreed, shared programming is an immensely useful feature for numerical programming, including data science and machine learning. Lots of people will say that those should be written in C++, but I think the rise of machine learning & data science in high level languages argues against their point.

Yeah. Python is pretty standard now. To implement high throughput scoring on models written in python, I have to run multiple processes with one copy of the python model for each process. For large models like random forests, this can eat up a lot of memory.

Ideally, it would be a single model in memory with access from multiple threads. But that won't work right now cause GIL.

Re: Let's Remove the Global Interpreter Lock

#273

Post by happycube »

kllrnohj wrote: post #148
sqeaky wrote: post #123

Earlier quoted context omitted.

You are right about the majority of what you said, but I am pedantically picking on one point. CPU cores are getting faster, but they aren't doing it with clock speed, they are dispatching more instructions per cycle or otherwise making the work faster.

IPC gains per generation are vanishingly tiny, if they exist at all. Skylake -> Kaby Lake, for example, had no IPC improvements at all. A very small clock bump to the various tiers was it. Even if you look over a large generation gap there's only a ~20% IPC improvement going from an i7-2600K to an i7-7700K ( https://www.hardocp.com/article/2017/01/13/kaby_lake_7700k_v... ) 6 years & a shrink from 32nm to 14nm and all…

Yeah - I remember when five year old CPUs were basically useless!

(Kaby Lake is basically a new stepping of Skylake - if intel wasn't having problems with new process nodes it likely wouldn't have been released at all, and if it was it would've been used for a one-off chip in the same generation ala the 4770K)

Re: Let's Remove the Global Interpreter Lock

#274

Post by swift »

gnaritas wrote: post #250
kerkeslager wrote: post #231

Earlier quoted context omitted.

Your parent comment gives good advice, because the GIL is probably here to stay and so there's no use complaining about it. But the idea that multiprocessing gives better results than multithreading is ridiculous. In languages which don't have a GIL, threads are almost as capable as processes, but lighter weight. Threads are almost always preferable to processes in most languages. I understand why the GIL is still ar…

> In languages which don't have a GIL, threads are almost as capable as processes, but lighter weight. But also plagued with shared state concurrency bugs, something multi-processing completely avoids so... > Threads are almost always preferable to processes in most languages. No, they aren't. It's too easy to write buggy code with threads, it's a flawed model. Now it's certainly true that more people choose threads…

The question of shared state vs. message passing is orthogonal to processes vs. threads. Both techniques can be and are commonly used in both situations.

Re: Let's Remove the Global Interpreter Lock

#275

Post by ComputerGuru »

I can't believe it's 2017 and the official pypy updates come from blogspot; I thought this was a plea from a community member.

Anyway, really good on them to finally move on killing the GIL. It's been a long-time issue - the type that only gets worse the longer you ignore it. That said, I think today Python and GIL are synonymous and the entire Python ecosystem has almost evolved around the GIL. While I'm sure there are applications that would benefit from its removal, I think in the whole, the ecosystem will not change much because of this.

Re: Let's Remove the Global Interpreter Lock

#277

Post by btilly »

sevensor wrote: post #266
btilly wrote: post #249

Earlier quoted context omitted.

You might want to look at https://stackoverflow.com/questions/17785275/share-large-rea... for inspiration. If you need to share a large readonly structure, the best way IMO is that approach. Implement the structure in a low-level language that supports mmap (be very sure to make the whole structure be in the mmap'd block - it is easy to wind up with pointers to random other memory and you don't want that!) and have h…

Thanks for the link! Might be worth going down that path.

Good luck. Another benefit of this strategy is that you optimize that data structure using techniques that aren't available in higher languages. So, for instance, small trees can be set up to have all of the nodes of the tree very close together, improving the odds of a cache hit. You can switch from lots of small strings to having integers that index a lookup table of strings for display only.

The amount of work to do this is insane. Expect 10x what it took to write it in a high level language. But the performance can often be made 10-100x as well. Which is a giant payoff.

Re: Let's Remove the Global Interpreter Lock

#278

Post by andy_ppp »

Great, and I want be a billionaire with washboard abs. The main problem is none of the Python code that currently exists is thread safe so you might as well start again from scratch. Python is a needlessly complicated language with two important things; Numpy and TensorFlow. These use Python as a scripting language for C. Just move to Go, Scala or Elixir/Erlang if you want to avoid the GIL (or write anything parallel). You can thank me later!

Re: Let's Remove the Global Interpreter Lock

#279

Post by gnaritas »

kerkeslager wrote: post #267
gnaritas wrote: post #264

Earlier quoted context omitted.

> So I'm not sure why you think processes are inherently safer than threads. Because they remove the unsafe way of sharing state from the programmer. The issue isn't that state can be shared correct in threads, it's that it doesn't have to be done correctly and programmers are simply terrible at doing it right. > There are a ton of threading models out there which don't rely on explicit locking, and there are even so…

> Because they remove the unsafe way of sharing state from the programmer. The issue isn't that state can be shared correct in threads, it's that it doesn't have to be done correctly and programmers are simply terrible at doing it right. Please read what I said before the part you quoted. In fact, maybe read the rest of the chain of comments--the topic of conversation is threads versus processes in Python, and thread…

I know exactly what you said, I "know" multi-threading doesn't require shared mutable state, I never claimed it did.

Don't presume to tell me what topic I might want to digress on, if you don't want to reply then don't, no one forced your hand.

Re: Let's Remove the Global Interpreter Lock

#280

Post by gnaritas »

pertymcpert wrote: post #268
gnaritas wrote: post #264

Earlier quoted context omitted.

> So I'm not sure why you think processes are inherently safer than threads. Because they remove the unsafe way of sharing state from the programmer. The issue isn't that state can be shared correct in threads, it's that it doesn't have to be done correctly and programmers are simply terrible at doing it right. > There are a ton of threading models out there which don't rely on explicit locking, and there are even so…

Not the person you replied to, but this thread is really frustrating to read. Multithreading does not imply shared mutable state.

No one claimed it did. Threaded code is plagued with bugs, it was not claimed that implies all threaded code uses shared state. Your frustration is unwarranted.
Post reply on HN