Week 6: Google Colab

Hey guys, welcome to week 6, where I used Google Colab to try to code a simple summation program using multiprocessing. 

First off, some general useful information I learned this week is the difference between multithreading and multiprocessing. CPU-bound computationally heavy tasks benefit from multiprocessing, which means processes are run at the same time on multiple cores. They don’t share a memory and have separate data/memory, which is why we use mpi4py, a message passing interface. I/O bound problems benefit from multithreading, which uses multiple threads within one problem. I/O bound just means the program relies on lots of input and output information, for example user input. For LBM, we use multiprocessing because the thing we’re trying to speed up is computing the distribution across the channel, not really I/O related stuff. 

Google Colab and Multiprocessing 

I tried out using Python’s multiprocessing library in Google Colab. The documentation for multiprocessing can be found here. First, I’m just seeing how many cores are available on Colab and thus how many subprocesses I can run in parallel. Here, I’m trying to get familiar with multiprocessing with a simple example of a summation program. The idea here is that if I want to sum all numbers 1 to n, I divide it up into summing numbers 1 to n/2 and n/2 to n. These two processes run at the same time, and at the end we just need to add the two results to get the actual sum. 

Processes are created by using the Process object’s start method after initializing a Process. Value is something we can store shared memory in. The “d” argument when creating sumval is saying that we want its value to be a floating point number. After creating 2 processes and starting them, we need to call the join() method as well.  

The results look like this: not was hoping for! Though the final answer is right. If you look past the weird spacing, you can see that the two processes are summing/printing their numbers simultaneously. It goes 1, 11, 2, 12, 3, 13, 14, 4, 15, 5, 16… wait where did 17 go. I’m still figuring out what’s wrong with this piece of code, but it seems to be somewhat working.  

We definitely can’t see a speed-up in runtime when numbers are this small, so I also tested this with larger numbers. Here, I’m timing summing numbers from 1 to 100,000 in parallel and normally. Except the summing itself didn’t work… I have yet to figure out why, but I’ll come back and update my blog when I do.  

Once I get this example working, I’ll move onto parallelizing my LBM model. Kind of a rocky week, but I’m learning! 

Thanks for following along, see you next week.