Let's Remove the Global Interpreter Lock

Re:Let's Remove the Global Interpreter Lock by throwaway613834 on Monday August 14, 2017 @07:14PM (#15013887)

> 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.

[ Parent | on HN ]

Re:Let's Remove the Global Interpreter Lock by jzwinck on Monday August 14, 2017 @09:22PM (#15014585)

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...

[ Parent | on HN ]

Re:Let's Remove the Global Interpreter Lock by goerz on Tuesday August 15, 2017 @10:58AM (#15018787)

Is there a way to disable this? In an HPC environment, I don't want routines going multi-core without my explicit permission, under any circumstances. I will already have manually set up the parallelization to be at the highest logical level. If using Python, that usually means I have planned out the number of processes to be equal to the number of cores. If each process then starts doing its own multicore calculation (badly load-balanced!) it overtaxes the node and slows everything down.

I really wish numpy/pandas/scipy wouldn't do this kind of uncontrollable parallelization.

[ Parent | on HN ]

Re:Let's Remove the Global Interpreter Lock by yaroslavvb on Tuesday August 15, 2017 @07:18PM (#15023619)

Underlying implementations often have a way to disable parallelism, ie, OMP_NUM_THREADS=1 or MKL_NUM_THREADS=1

[ Parent | on HN ]