This is Google summer of code (GSoC) 2017 final project report. The project was under the Python software foundation. Project name: Optimizing Stingray. Stingray is an open source Python library which aims to help astronomers study black holes activity, and for which I am proud that I have been participating in such a project.
Stingray deals with fairly large sized objects, performing various operations on them. That is why optimization is always a must, otherwise we will compromise accuracy and precision for an acceptable computing time. That is why we had to work to make sure Stingray's source code is optimized as much as possible in terms of both memory and time.
My work in the project can be divided into three parts.
- Analyze the already written source code.
- Insert modification to the already written code.
- Add a new module which computes in parallel mode.
This step's purpose is to conduct a timing analysis through the most common files in the library, to identify Stingray's bottlenecks. For Analyzing the code I created a github repo Which was made specifically for the GSoC project. I carefully created a test script for every method I analyzed. I then recorded the values of the completion time across different sizes and plotted a graph which represented the time complexity of the method being analyzed. The scripts written in the repo should be used even after GSoC to make sure that Stingray is still running in the acceptable time limits. If there was a model that we needed extra details on, not just the execution time. I used the profiling method in python to create .prof file and used [Snakeviz] (https://jiffyclub.github.io/snakeviz/) to view all the methods being called and how much exactly does each method takes.
This step was after the analysis we found out that there are methods that behave in a quadratic scale behavior and had to be fixed right away. I introduced two solutions to two methods to reduce their complexity and the solutions got accepted and merged, as it can be seen from the two (closed) Pull Requests: First, Second The idea behind the solution was to use data structure that fitted the logic perfectly. The speedups that the solutions made is mentioned in each of the pull request. I then followed up with a bug fix that my mentor pointed out later. Bug Fix
After the first two steps we were sure that everything in Stingray now scales linearly. What was now left was to make a good use of having multiple cores and have Stingray uses those cores to distribute processing on the cores. A note to have in mind is achieving complete parallelism in python is very hard, as I had to learn in the project. It is because python has something called GIL (Global interpreter lock) which basically locks the python objects created in a thread and no more than one thread can access those objects at any given time.
The workaround to this problem is by using multiple processes instead of multiple threads. Creating completely different processes is a good way to workaround the GIL but gets very challenging to synchronize between the processes.
My mentor suggested to use a library to do this, which is Dask. It took me a while to get the hang of it. I started writing a working example and initiated the first PR to introduce a new module in stingray which is a generic interface to be used across the library to execute in parallel and make use of all available cores.
Whenever we faced a bug, the debugging would be a nightmare because the generated errors would come deep from the dask's library and would be almost impossible to follow. Also there was multiple downsides to dask in the way it synchronizes between the processes that it creates which takes a lot of time.
I was then suggested by my mentor to use the built in library MultiProcessing to achieve the intended. Stingray.Parallel now has both implemented in it (Dask and MultiProcessing).
This Pull Request has it all. All the work I've did in the final stage is there. I've written this module while keeping in mind that the parallel processing code must be separated from the library core code. So it was very challenging to write the module in a way that everything in there must be as generic as possible.
The commits in the PR begin with implementing Stingray.parallel using only dask. Then I added another implementation using multiprocessing. When I was done with it, I added the test_parallel module to test the code I've written to ensure its stability.
The code in the Pull Request is ready and runnable and it already achieved a good speedup as it is mentioned in the Pull Request. But it is currently failing in some of the tests that ensures the compatibility with different Python versions and different platforms. It should be fixed shortly and then it will be ready for merge.
The current way the multiprocessing module synchronizes between Processes is slightly better than other libraries, but is still wasting a lot of time, almost 50% of the time is consumed when the processes finishes the computing part and starts synchronizing. This has to be done in a better way, and once that is done there will be huge speedups in the library using Stingray.parallel.