[FIXED] scikit-learn LinearRegression and RandomizedSearchCV and their n_jobs parameter relation

Issue

If you use LinearRegression model with RandomizedSearchCV model selector, and, let's say we use n_jobs=-1 for both of them, meaning all CPUs should be used in parallel if possible, how will this be handled, since both are signaled to take advantage of all the available CPUs?

Solution

Q : "how will this be handled, since both are signaled to take advantage of all the available CPUs?"

The very same way, as if having 4 tyres, booted on wheels, fully pressured all prepared to be mounted on car and ride for a weekend trip, but having two different targets - one of yours, going in your car, and another, that your mother has looking forwards for weeks, with her car - as both cars use the same size of the wheels, you can mount 'em on either one.

So,
you can indeed "take advantage of all the available" wheels, but you have to decide, whether going with your car towards your target location, or whether pleasing your mum and let her car get all the available wheels, so it can run towards her target of choice.

Any wheel-interleaving or wheel-sharing strategies may work for some arcane modes of trip to happen, yet there will also come some strange add-on costs for sharing / swapping the wheels (as an example after each even 2-hours, your mum will let you take one wheel from "her" car, leaving her riding on remaining three wheel at lower stability and lower speed, yet you will not make much progress with having a one and only one wheel, will you? Yet, your mum will pay the costs of you having the one wheel "borrowed" at no much gain for you at all, plus you will have to run from your car location to your mum's car location ( if you were going South and your mum was riding Northwards, you will make a pretty growing mileage each time you "borrow" + each time you "return" a borrowed wheel, will you not? ) and it will be your duty to take all such measures to return that "borrowed" wheel to your mum's car no later than before a duration of 2-hours has passed ( remember, as a good child of your mother, you will never exceed the fair-sharing duration, will you? )

---

The result ?

Neither your mother nor you will reach the target in a same time, as if you both were riding without this available-wheel-"capacity" over-subscribed manner. Plus you will expense all the add-on costs of moving a "shared" wheel here and there and here and there ( losing time, losing energy, destructing all expensively cache pre-fetched data you will have to pay againg for re-fetching next time you need 'em used - here paying, perhaps in silence and hidden from your sight hundreds of [ns] instead of ~ 0.5 [ns] if drawn from L1-cache ( where the data was before you had to return the wheel to your mum's car last time ... )

Sad model.

Poor performance.

So one shall rather well understand what goes on under the hood of the joblib.Parallel & other process-based parallelism, knowing how the computing hardware works, because a syntax is blind to these impacts and documentation is not going so far as to explain the general public what will happen after over-subscribing takes place in computing-intensive processing-payloads.

---

Still in doubts ?

Easy - make a test and benchmark the resulting times for n_jobs set as ( N, 3N/2, N/2, N/3, N/4 ), N being the count of hardware CPU cores and read some details in BIOS on your actual computing platform's HyperThreading setting. Last but not least, memory-I/O usage patterns matter no less than the "wheel"-depicted CPU-core "swapping".

Answered By - user3666197