This seven-part, quick-read workshop series is taken from the real-world case study whitepaper, "Porting Financial Markets Applications to the Cell Broadband Engine Architecture" (written by John Easton, Ingo Meents, Olaf Stephan, Horst Zisgen, and Sei Kato, IBM Systems and Technology Group, June 2007; see Resources). You can probably spend less than 10 minutes reading each installment and come out at the end with a strong basic knowledge of the requirements for effectively porting a compute-intensive application (in this case, a financial market application) to the Cell/B.E. processor.

Editor's note: The performance results in this series were obtained using Versions 1 and 2.1 of the Cell Broadband Engine Software Developer Kit (SDK). The current version of the SDK, the IBM Software Development Kit for Multicore Acceleration, Version 3.0, has recently become available and offers many enhancements in functionality, ease of use, and performance over the earlier versions. While the results documented in this article are correct for the earlier versions of the SDK, different results will be obtained with SDK 3.0. Watch for updates to the articles in this series that will describe the latest performance improvements obtained using SDK 3.0.

Introducing the application

The example application modified in this article is a piece of code used to price a European Option to highlight the benefits of the Cell/B.E. blade. A European Option is a simple financial contract with strict terms and properties that gives the buyer the right to trade a given asset at a specific price on a specific date. It is generally an option that can be exercised only at the end of its life. By contrast, an American Option can be traded at any time between its purchase date and the date at which the contract expires. Because a European Option is traded on a fixed date, it is a simpler calculation to perform because the time variability of the American Option is removed.

You can use several different models price a European Option, depending on the type of asset that underlies it. For example, an option based on currency is calculated using a slightly different model than an option based on futures. In the example described in this series, the calculation is based on a simple Monte Carlo simulation technique. You will generate 200,000,000 uniform, pseudo-random numbers. These numbers are transformed to a log-normal distribution using a Box-Müller transform. Using the random numbers generated, you will execute the financial model repeatedly to simulate a random walk. The final stage of the analysis will be the calculation of the relevant statistics, such as the minimum, maximum, and average and the 95 percent quartile for losses.

Back to top

Getting the most performance out of Cell/B.E. technology

This work has led to a few observations to share with those readers who would like to perform a similar porting exercise.

Offloading for performance enhancement

The performance data shows that a single SPU is capable of delivering almost half the performance of an Intel® general purpose processing core. As such, the first recommendation has to be to use the performance of the SPUs by offloading as much of the computation onto the SPUs as possible.

Exploiting the SIMD

To really make the SPU perform well, exploiting the SIMD nature of the SPU is vital. Although the compiler technology, especially that provided by XLC, provides some capability to auto-SIMDize the input program code, the very flexibility of a language such as C means that this technology does not always make a particularly good approximation of the best SIMD code.

As such, to take advantage of the SMID nature fully, it might be more appropriate to actually write the SIMD code yourself rather than relying on the compiler to do it. The key to doing this is to make sure that the way you have chosen to rewrite the algorithm to exploit SIMD is optimal for the given application and the input data. In certain situations, such as the case where the source code is heavily templated C++, or where the code makes significant use of object-oriented constructs, you might find that starting from scratch is a much quicker way to implement application code.

Back to top

Drawing some conclusions

Many organizations are investigating the use of acceleration technologies to improve the performance of their algorithms, because their abilities to exploit ever-increasing numbers of general-purpose processors must be reconciled against the challenges that they face with space, power, and cooling issues. So, how is the Cell/B.E. system positioned against these other accelerator technologies?

At one end of the spectrum are the general-purpose processors from Intel and AMD that make up the majority of the computational infrastructures used by these organizations. The huge numbers of systems based on these processors give them several advantages over other technologies. There is a large supply of professionals skilled in working with them, which leads to lower skills costs, a lot of application development tooling, and therefore a large base of ISVs supporting these platforms. Couple these facts with the relatively easy code porting to these platforms, and it has meant that the majority of application codes run by the business run on systems based on these processors.

These general-purpose processors are very much regarded as jack-of-all-trades devices. They do suffer, though, in that they deliver relatively low performance for the area of the chip, and they do this with relatively high power consumption per computation.

At the other end of the spectrum is a number of what can only be described as esoteric technologies. These include Field Programmable Gate Arrays (FPGAs), Complex Programmable Logic Devices (CPLDs), and Graphics Processing Units (GPUs). Though there is a wide range of different devices here, these all typically offer high performance for their chip area and consume much less power per computation than the general purpose processors. Given this, these devices are highly efficient at addressing a very narrow task scope.

You might ask why their adoption has not been wider. This is basically because they are very much the opposite of the general-purpose devices: the skills to program them are rare and relatively expensive. If you join this with the lack of application development tooling, it leads to quite hard code creation and porting for these platforms.

The performance capabilities of these platforms are well understood, but realizing this performance is proving to be a challenge for many organizations. Assuming that you can find the skills to do this, the porting process is generally both slow and costly. This in turn leads to a miniscule ISV base for these platforms today.

So how does the Cell Broadband Engine technology compare? You might expect that the nature of the Cell Broadband Engine environment means that it would be closer to the FPGAs and GPUs than the general-purpose processors. This is not the case. The facts that the Cell/B.E. environment runs a standard Linux® operating system and has a growing range of development tools, ISV applications, and standard libraries means that it is actually much closer to the general-purpose processors than might be expected. Working with other customers in this space has simply confirmed this. They all regard the Cell/B.E. platform as significantly easier to port code to than FPGAs and GPUs.

In an industry where time-to-market is a key concern, this places the Cell/B.E. platform in a unique position: for the workloads that can exploit its capabilities, the Cell/B.E. environment offers excellent performance advantages at only a slightly longer time-to-market than the general purpose devices.

Regardless of the technology used, this series introduced that code optimization is critical to get the best out of any chosen platform. The days of simply recompiling application code to fully exploit a new processor are over. Simple recompile will forever be relegated to a second-class effort position when it comes to effective porting. In the future, programmers will have to use increasingly advanced programming techniques that take into account the management of both code and data parallelism to get the best out of any architecture. The abilities of programmers to adapt to these new technologies will be critical to the success of organizations that are finding that they can no longer achieve commercial advantage simply by throwing more power at the problem.

Constraints over power, space, and cooling issues and an increasing pressure to innovate are causing organizations to reconsider strategies when it comes to designing the compute infrastructures of the future. A system based on a processor as capable as the Cell Broadband Engine processor has to be a strong contender, not only in terms of its computational power, but also its data movement and manipulation abilities. Couple this with a number of strong customer proof points, a growing ecosystem of tools, support from key Independent Software Vendors, and the results of experiments such as this one to see that the Cell/B.E. platform shows that it is extremely credible for taking on the technology challenges of these organizations.

Back to top

Acknowledgments

Many other individuals contributed (both knowingly and unknowingly) to this piece of work. The authors wish to acknowledge their kind contributions. Without this assistance, this paper would never have been written.

Resources

Learn

• Use an RSS feed to request notification for the upcoming articles in this series. (Find out more about RSS feeds of developerWorks content.)
  
  
• Check out the original whitepaper, "Porting Financial Markets Applications to the Cell Broadband Engine Architecture" (alphaWorks, June 2007). The original whitepaper combines the contents of this entire series. It also provides a tidy introduction to the Cell/B.E. architecture, and it explains why the processor is important, especially for compute-intensive financial market applications.
  
  
• See "Introduction to the Cell Multiprocessor" (IBM Journal of Research and Development, 2005) for an introductory overview of the Cell/B.E. multiprocessor's history, the program objectives and challenges, the design concept, the architecture and programming models, and the implementation.
  
  
• Go to "Porting practices: Compute-intensive applications" (developerWorks, June 2007) for help bringing a compute-intensive application to the Cell/B.E. architecture.
  
  
• Read "Tech tips: SPU vector intrinsics at your fingertips" (developerWorks, May 2007) for a handy list to keep you on the right side of common Cell/B.E. SPU vector intrinsics. This article was extracted from a longer article, "Programming high-performance applications on the Cell BE processor, Part 5").
  
  
• Review "Cell Broadband Engine Architecture and its first implementation" (developerWorks, November 2005) for an up-close look at the performance figures and characteristics of the first implementation.
  
  
• Explore the QuantLib project, which is a free/open-source library written in C++ with a clean object model for modeling, trading, and risk management in real-life. It is exported to different languages such as C#, Objective Caml, Java™, Perl, Python, GNU R, Ruby, and Scheme.
  
  
• Learn more about the Mersenne-Twister. It is a very fast, pseudo-random number-generating algorithm that uses memory very efficiently. The algorithm has a far longer period and far higher order of equidistribution than any other implemented generator.
  
  
• Refer to "Implementation of a Mixed-Precision in Solving Systems of Linear Equations on the CELL Processor" for details on the implementation of code to solve a linear system of equations using Gaussian elimination in single precision with iterative refinement of the solution to the full double-precision accuracy.
  
  
• Bring up the Software Development Kit 2.1 Installation Guide Version 2.1 (PDF) to walk through installation, configuration, and many of the basics that you need to know to get started with development. Two companion pieces, "Cell/B.E. SDK 2.1: Setting up Fedora Core 6" and "Cell/B.E. SDK 2.1: Understanding the terminology" (developerWorks, April 2007), can help you get the requisite FC6 up and running, and they provide a quick reference to Cell/B.E. terminology.
  
  
• To learn more on Cell/B.E. programming, try the developerWorks series:
  • "Programming high-performance applications on the Cell/B.E. processor"
  • "PS3 fab-to-lab"
  • "The little broadband engine that could"
  
  
• Refer to the Cell Broadband Engine documentation section of the IBM Semiconductor Solutions Technical Library for a wealth of downloadable manuals, specifications, and more.
  
  
• Sign up for the developerWorks newsletter and get the latest developer news and Cell/B.E. happenings delivered to your inbox each week. Check Power Architecture when you sign up to receive Cell/B.E. news in your newsletter.
  
  

Get products and technologies

• Get the OpenMP API to learn about a portable, scalable model that gives shared-memory parallel programmers a simple and flexible interface for developing parallel applications. The API supports multi-platform, shared-memory parallel programming in C, C++, and FORTRAN on all architectures, including UNIX® and Windows NT® platforms.
  
  
• Find the centerpiece of Cell/B.E. development at latest Cell/B.E. SDK release, version 2.1.
  
  
• Locate the IBM XLC compiler for porting efforts. It is optimized for the Cell/B.E. processor.
  
  
• Find all Cell/B.E.-related articles, discussion forums, downloads, and more at the IBM developerWorks Cell Broadband Engine resource center: your definitive resource for all things Cell/B.E.
  
  
• Contact IBM about custom Cell/B.E.-based or custom-processor based solutions.
  
  

Discuss

• Participate in the discussion forum.
  
  
• Check out the Cell Broadband Engine Architecture forum to get your technical questions about the processor answered. Juicy problems and answers from the forums are rounded up periodically and highlighted in the "Forum watch" blog series.
  
  
• Go to the Power Architecture blog for news, downloads, instructional resources, and event notifications for Cell/B.E. and other Power Architecture-related technologies. You can find the popular "Forum watch" blog series (Q&A roundup) and the "FixIt" technology updates.
  
  

About the authors

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introducing the application
• Getting the most performance out of Cell/B.E. technology
• Drawing some conclusions
• Acknowledgments
• Resources
• About the authors
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

My developerWorks community

Dig deeper into Multicore acceleration on developerWorks

Special offers