Python SARIMA model is automatically using all cores of CPU. How?

1
votes

I am running a Moving Average and SARIMA model for time series forecasting on my machine which has 12 cores.

The moving average model takes 25 min to run on a single core. By using the multiprocessing module, I was able to bring down the running time to ~4 min (by using 8 out of 12 cores). On checking the results of the "top" command, one can easily see that multiprocessing is actually using the 8 cores and the behaviour is as expected.

Moving Average(1 core) -> CPU Usage for Moving Average 1 core

Moving Average(8 core) -> CPU Usage for Moving Average 8 cores

I ran the same routines using the SARIMA model first without using multiprocessing. To my surprise, it was automatically using all the cores/distributing work on all cores. Unlike Moving Average model(Image 1) where I could see the CPU Usage of the process to be 100% for the single process and ~800% cumaltively on using 8 cores, here the CPU Usage for a single core only was fluctuating between 1000%-1200%(i.e all 12 cores). As expected, the multiprocessing module didn't help me much in this case and the results were far worse.

SARIMA(1 core) -> CPU USage Sarima 1 core

SARIMA (8 core) -> CPU Usage Sarima 8 core (Instead of one process using 1200% in this case, some processes go over 100% )

My question is why is the OS automatically distributing work on different cores in case of SARIMA model, while I have to do it explicitly(using multiprocessing)in Moving Average Model. Can it be due to the style of writing the python program?

Some other info:

  1. I am using http://alkaline-ml.com/pmdarima/0.9.0/modules/generated/pyramid.arima.auto_arima.html for SARIMA Tuning.

  2. I am using process queue technique to parallelise the code

  3. SARIMA is taking 9 hrs on 1 core(maxing at 1200% as shown in above images) and more than 24 hrs if I use multiprocessing.

I am new to stackoverflow and will be happy to supplement any other information required. Please let me know if anything is not clear.

Updated: I had raised an issue on the official repo of pyramid package and the author had replied. The same can be accessed here: https://github.com/alkaline-ml/pmdarima/issues/301

1
pythonmultithreadingparallel-processingoperating-systemmultiprocessing
obviously, the SARIMA package you are using has implemented multiprocessing - luigigi
@luigig that was my hunch as well. However, I did not find any such details in the documentation. Also, I am training the model on a client level i.e. My code trains a different model for the 5000 clients I have. I am using multiprocessing to divide these clients among different cores since there computation is independent. Even if the SARIMA model did implement multiprocessing, it would have done so on the hyperparameter tuning. In such a case, the multiprocessing code for SARIMA should have performed better. - Mohit Munjal
maybe the multiprocessing isnt even implemented by the package itself, but by the solver they are using. by splitting the independent forecasts to multiple processes it's probably get slower because the processes must fight for computing power which takes more time then the sequential cumputing - luigigi
@luigigi well, not necessarily multiprocessing. - juanpa.arrivillaga
@juanpa.arrivillaga not necessarily. but it makes it clear what I mean - luigigi

1 Answers

0
votes

The obvious reason is that SARIMA is developed to work on multiple cores of the CPU. Whereas Moving average does not have that functionality implemented into it. It has nothing to do with your style of writing the code. It is just that the package authors have developed the package code in 2 different ways i.e

  1. No native multiprocessing support for Moving Average and
  2. Native multiprocessing support for SARIMA

One more point to correct in your understanding is that the OS is not automatically distributing work on different cores in case of SARIMA. The package code of SARIMA is the master who is distributing all the work on different cores of CPU since it was developed to support and work with multiple cores by it's authors.

Update:

Your hunch is that multiprocessing code with client level multiprocessing + native multiprocessing should perform better. But actually it is not performing better. This is because,

  1. Since the native multiprocessing of SARIMA is itself taking up the resources of all the cores of your CPU, what computation power will your client level multiprocessing have in order to speed up the process since all the computation power on all cores of CPU is being utilized by native multiprocessing of SARIMA?
  2. This is the way a linux OS or any OS works. When there is no CPU power left for a process(in your case it is for client level multiprocessing process), the process is placed in a queue by the OS until the CPU becomes available to it. Since your client level multiprocessing process is placed in a queue and is not actively performing since there is no CPU left at all, it is stalling up. You could refer Linux OS documentations for verifying what I have said.