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

Evaluating mixed-precision workloads

Given that the current implementation of the Cell/B.E. platform has limited double-precision floating point capabilities, there is a lot of interest in the work done by Kurzak and Dongarra (see "Implementation of a Mixed-Precision in Solving Systems of Linear Equations on the CELL Processor" in Resources) on mixed-precision calculations on the Cell/B.E. platform. In their paper, an approximate solution to a system of linear equations is generated using single-precision arithmetic. This solution is then plugged into the equation, and the delta is computed. Then a second iteration using double-precision arithmetic is started, based on the delta.

This approach cannot be mapped directly to the problem of pricing European Options using a Monte Carlo method, but you can do something similar by generating 32-bit (single-precision) random numbers and using these for the double-precision cases. In essence, rather than performing all of the calculations exclusively using single- or double-precision, only those parts of the calculation that actually need double-precision are calculated using double-precision. This increases the programming effort needed slightly: first, to identify which parts of the code should use which sort of precision and, second, to make the appropriate changes to the code. But it also delivers a substantial performance improvement due to the outstanding single-precision performance of the chip.

We recently investigated a couple of potential uses of this mixed-precision technique for the European Option pricing code. In both cases, the pricing of the European Option is still performed using double-precision arithmetic. The Mersenne-Twister random-number generator is where we applied the mixed-precision mathematics.

In the first case, a double-precision random variant is generated by concatenating two single-precision random variables. In the second case, the double-precision variant is formed by generating one single-precision random variable and then turning it into a double-precision random variable by doing a double-precision division. The second case requires generating half the number of random numbers (200,000,000) compared to the first case (400,000,000), but the second case does require additional double-precision arithmetic. The determining factor here is whether the doubling of the single-precision mathematical component in the first case is offset by the double-precision activities in the second case.

See Table 6 for an example. (Tables and figures are numbered consecutively throughout the series to match the versions in the original whitepaper.)

Table 6 shows the results in which:

• CC_DP_MT = Concatenation Double-Precision Mersenne-Twister
• CC_DP_SDK = Concatenation Double-Precision SDK
• M_DP_MT = Division Double-Precision Mersenne-Twister
• SP_MT = Single-Precision Mersenne-Twister
• SP_SDK = Single-Precision SDK

Figure 4 shows the results.

Because we completed the various optimizations over a number of months, many things changed, so unfortunately, we cannot make a direct comparison between these mixed-precision numbers and those described in earlier experiments. In Part 4, you could see a factor-of-four improvement of the Mersenne-Twister random-number generator over the SDK-supplied one. After that, the optimized code in the SDK changed significantly with the way that vectorized random-number generation is performed. The rejection method is further causing uncertainty due to the scalar nature of that process and the randomness involved.

The SDK also changed considerably. The original porting of the code was performed using SDK 1.0. The current release is SDK 2.1. We observed that running the binaries on a QS20 blade running SDK 2.1 was approximately twice as fast as running the same binaries on a QS20 running SDK 2.0. For a proper comparison, the firmware and kernel versions should also be taken into consideration, but this shows the continuing advances being made in terms of the SDK and its performance. The following table shows examples of the speedup between SDK 2.0 and SDK 2.1:

We've since used some additional optimization techniques to improve performance even further. These techniques include:

• Unrolling more parts of the Mersenne-Twister random-number generator function that generates 32-bit unsigned integers.
  
  
• Adding additional software pipelining by parallelizing computation and data loads into the two pipes of the SPE's execution unit.
  
  
• Pre-calculating items, such as:

  a[0]=<something>; for (i=0;i<N;i++) { sinf4(a[0]) ; sinf4(a[i+1)); ...... }

  
  Precalculating items reduces the runtime and enables the compiler to make a better job of optimizing the code.
  
  
• Introducing new variables to eliminate dependencies and allow the compiler to make better use of the two pipelines.

This demonstrates that you can use the outstanding single precision capabilities of the Cell/B.E. environment to outweigh the constraints of the limited double-precision performance of the current Cell/B.E. processor implementation.

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
• Evaluating mixed-precision workloads
• 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