The law of parallel processing

Have you ever seen someone write bad code and try to solve the performance problem by throwing more hardware at it? Higher-level languages like Python and Java make it easier to write code, but they also make it easier to write bad code. This is because these languages do not force programmers to think about the performance of their code in the same way that lower-level languages like Assembly and C do. As a result, programmers who use higher-level languages can sometimes be lazy and write code that is not as efficient as it could be

In a recent article, I discussed the following scalability graph:

Let's discuss how you get parallel efficiency gain. A formula known as Amdahl's Law formulated by former IBM engineer Gene Amdahl discusses that the code's theoretical speedup is directly proportional to the least amount of work that can be parallelized.

Why are some technologies more optimized than others? Let’s find out. Parallel processing is the single biggest driver of computing efficiency. Imagine you land at an airport and have to move your luggage to the taxi rank.

1. Imagine it takes 1 person 1 minute to move one trolley from the carousel to the taxi rank. If you have 1 trolley, for 10 people, it will take 10 minutes to complete. This is serial processing. 
2. If you have ten trolleys for ten people, it will only take 1 minute to complete the task. This achieves the maximum parallel efficiency of 10X. 
3. If five people insist on using the same red trolley, they must do their tasks sequentially. No matter how many free trolleys are available, completing them will always take 5 minutes. This results in a maximum parallel efficiency of 2X even though idle resources are available. 

Let's examine this analogy in the world of parallel databases:

Here is an example of three different types of databases processing SQL (Above picture credit Daniel Graham ). Imagine we have 100TB of data to analyze.  

1. On the left is a serial processing database.  It chugs along at the speed of a single server, usually only a  single CPU on that server.  It is the slowest method. It is like having a single trolley for everyone at the airport.  
2. In the middle, we see some parallel processing where multiple servers work together to do the table scans, joins, sorting, and oops. It doesn’t do sorting in parallel.  That’s a massive bottleneck in performance when terabytes of data are involved. This is like a few people insisting on the red trolley. This means resources are waiting in idle. No matter how many nodes you add to the configuration, you cannot speed it up unless you eliminate the "red trolley."
3. On the far right is the max efficiency system, which does everything as much as possible in parallel.  This will be the fastest solution.  To go faster, we add more servers to the cluster.

In short, the more parallel efficient your system is, the better would be the system's throughput. A simple understanding of this principle can help you in writing better code. Always, the maximum parallel efficiency of your code is determined by the least amount of code that can be parallelized.

If you like, please subscribe to the FAQ on Data newsletter and/or follow Fawad Qureshi on LinkedIn.