Explicit Parallelism

Even before the development of the Intel^® Itanium^® processor family^[19] and its EPIC architecture, the business processes in an enterprise environment were massively parallel, though most computers in use to manage these business processes today are not. Things don't happen in a sequential order—multiple things are happening at the same time throughout the entire day in order for the business to run smoothly.

^[19] Intel and Itanium are registered trademarks or trademarks of Intel Corporation or its subsidiaries in the Unites States and other countries.

Were the world to run in a purely sequential manner, output would be reduced to a crawl. Thus, the concept of doing things in parallel at the microprocessor level makes intuitive sense; the challenge is to make this happen “explicitly” rather than the implied parallelism of today's RISC systems where the parallel operations occur on the fly.

Finding Parallelism on the Fly

Past hardware efforts, specifically superscalar RISC with out-of-order execution, focused on finding small bits of parallelism on the fly. As the RISC processor gets instructions from the compiler, it actually has an instruction 'buffer' that tries to determine what it can process in parallel. For example, the buffer's analysis might determine that as the processor executes a set of calculations that are embedded in a given loops, it can also execute the code immediately before it while the calculations run.

But given the fact that the processor has to do this in the middle of fetching and executing instructions, the selections for parallel computing cannot be very large. It requires a fairly high level of complexity to even figure out what limited operations can be done in parallel. Therefore, processors today can actually run in a limited parallel mode—but by and large they are still confined to single instruction threads within software modules.

Multithreading and Finding Better Parallelism Opportunities

Operating system efforts focused on multiple threads and processes. Typically, this is through what is called 'multithreading'. This increases system throughput, but it's ultimately bounded by processor throughput. The processor remains the 'bottleneck' in the system.

By moving to the new EPIC parallel architecture, we're actually able to move the responsibilities for finding the opportunities for parallelism back into a software model. Once the compiler is running, it has to 'see' the entire program. So it gets a very broad look at the information that needs to be processed, and locates many more opportunities to run items in parallel.

The compiler can now identify opportunities for second level parallelism, or even break a program into separate parallel 'blocks'. This achieves a much broader scope, and creates new opportunities to exploit parallelism. This one development alone allows us to move beyond the current limitations of semiconductor technology. Figure 7-2 below provides a graphic illustration of how the compiler would work in this architecture environment.