I've spoken with a number of vendors who are doing their best to offer tools making it possible to create configurations that process transactions presented by millions of people not just hundreds of thousands people as used to be the high end of the spectrum only a few years ago.
In almost every case, these innovative people are trying to exploit the power and scalability of parallel architectures without forcing developers to face the pain of decomposing their applications or their data structures so that they can be processed by thousands of processors simultaneously.
This is no mean task since may of today's commercial applications have a number of dependencies (this must be processed before that and that must be processed before the next thing) making it difficult to segment functions from one another. How then do these suppliers make the magic work?
How can we accelerate a single system? Enter MultiprocessingFirst let's look at how to accelerate a single system. This has been done by adding processors and making the operating system deal with memory management and processor scheduling issues. The industry has seen the number of processors found in a single computer increase from 2 to 256 and beyond. SGI, for example, offered a 1024 processor system a number of years ago to address the computing needs of its customers.
Pipelined ArchitecturesThe next step was to examine the microprocessor and create clever ways to segment processing into a number of functions that could be executed in parallel. As each of these "piplelines" became ever more complex and powerful, the industry finally reached the state of having multiple complete CPUs on a single chip, often described as multicore chips.
Mulitcore chip architecturesAt this point, we've seen announcements of 2, 4 and 8 processors on a single die. If pipelined architectures are combined with multicore technology, the number of execution units in a single system could easily reach into the thousands before too long.
When a single system just isn't enoughThe next step clearly is to get more systems involved in the task at hand. There have been so many industry catch phrases to describe this approach that I won't attempt to summarize them here. In all cases, an application was closely examined to determine places where "distributed processing sauce" could be placed between functions so that a function could be executed on a single larger system or executed in parallel by a number of systems.
Here are a few places where the "distributed processing sauce" is applied:
- Between the user interface and the application logic
- Between the application logic and the data management
- Within the application logic itself
- Within the data management itself
- Between the data management and storage management
Where do we go from here?Applying parallel processing techniques to traditional commercial applications has been challenging because, in many cases, these applications were never designed in a way that allowed multiple copies of functions to be "spun up" so that data could be processed by many systems.
I plan to examine some of these approaches in future posts. Most of them involve making the data available to a number of processors in a controlled fashion so that one processor's activities don't "step on" what another processor is doing.