In this seven-part, quick-read workshop series, taken from the real-world case study whitepaper, "Porting Financial Markets Applications to the Cell Broadband Engine™ Architecture" (see Resources), you can spend minimal time reading each installment and complete the series 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.
The example application that the modification applies to 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 just 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 only be exercised at the end of its life. In constrast, an American Option may be traded at any time between its purchase date and the date at which the contract expires.
As such, because a European Option is traded on a fixed date, it is a simpler calculation to perform since the time variability of the American Option has been removed.
A number of different models can be used to price a European Option depending on the type of asset that underlies it. For instance, an option based on currency is calculated using a slightly different model than an option that is based on futures. In the case described in this series, the calculation is based on a simple Monte Carlo simulation technique. A large number (200,000,000 in this case) of uniform, pseudo-random numbers needs to be generated. These numbers are transformed to a log-normal distribution via a Box-MÃÂ¼ller transform. Using the random numbers generated, the financial model is executed repeatedly to simulate a random walk. The final stage of the analysis is the calculation of the relevant statistics, namely the minimum, maximum and average and the 95 percent quantile for losses.
To run the performance tests, the following parameteres were used on the modified code:
- Compiler used: spuxlc, ppuxlc.
Compiler optimization setting:
- Random-cnumber generation method: sdk.
- Precision: single.
- Number of evaluations: 200,000,000.
Please note that the code was developed using the IBM ®Full-System Simulator for the Cell Broadband Engine Processor that can be downloaded as part of the SDK (see Resources). The simulator provides a complete Cell/B.E. development environment, including a Linux kernel for Cell/B.E. blades, Linux support libraries, tool chains, a system simulator, source code for libraries, and samples.
Though the simulator provides a cycle-accurate simulation, in order to get a better feel for the real performance of the system, we ran the benchmark code on an early prototype version of the Cell/B.E.-based blade -- the IBM BladeCenter QS20. The major difference between this and the version of the blade that is now generally available was that this prototype was running at 2.4GHz instead of 3.2GHz.
Table 2 shows the initial performance results that were achieved. (Tables and figures are numbered consecutively throughout the series to match the versions in the original whitepaper.)
Table 2. Performance by number of SPUs (single precision)
|Number of SPUs||Elapsed time (seconds) 2.4 GHz Cell/B.E. processor (measured)||Elapsed time (seconds) 3.2 GHz Cell/B.E. processor (estimated)||Speedup|
As you can see from the Speedup column, the performance speeds up linearly as more SPUs are applied to the problem. Figure 1 illusetrates this in the graph which plots both run-time and speedup against the number of SPUs.
Figure 1. Plot of the single precision run-time and speedup against the number of SPUs
Many organizations require double-precision arithmetic. The initial target marketplace for the Cell/B.E. technology -- home entertainment systems -- typically doesn't need this precision, so the initial implementation of the Cell/B.E. environment provides very limited double-precision support in hardware.
The SPU supports both single- and double-precision floating-point operations. Single-precision instructions are performed in four-way SIMD fashion, fully pipelined; whereas, double-precision instructions are partially pipelined. The data formats for single- and double-precision instructions are those defined by IEEE Standard 754; however, the results calculated by single-precision instructions depart from the IEEE Standard 754 by placing emphasis on real-time graphics requirements that are typical of multimedia processing.
Although some believe that the Cell/B.E. platform cannot do double-precision mathematics, Table 3 shows that it can: A primarily software-driven approach is used rather than the double-precision capabilities of the hardware.
Table 3. Performance by number of SPUs (double precision)
|Number of SPUs||Elapsed time (seconds) 2.4 GHz Cell/B.E. processor (measured)||Elapsed time (seconds) 3.2 GHz Cell/B.E. processor (estimated)||Speedup|
In Table 3, the effective factor of two increases in the run-times is due to the size of the SIMD vector. Only two double-precision (64-bit) numbers are generated per SPU at once instead of four single-precision (32-bit) numbers. As such, use of double-precision numbers requires twice as many loop iterations. Note that as the number of SPUs is increased, the parallelization still improves by a factor of 157.3 / 9.9 = 15.88, again equating to a linear speedup. This linear relationship is clearly seen in Figure 2.
Figure 2. Plot of the double precision run-time and speedup against the number of SPUs
To get a feel for the capabilities of the Cell/B.E. platform in running this application, it is worth comparing the previous figures with the figures produced from running the original customer code on the typical technologies being deployed by organizations. Table 4 shows this comparison.
Table 4. Comparison of code runtimes (in seconds) between different processor types and compilers
|System||Processor/Speed (GHz)||RAM (GB)||Operating System/Compiler||Original/Optimized||Time SP/DP|
|IBM BladeCenter HS20||Intel Xeon / 3.8||4||RedHat Enterprise Linux 4 / gcc||Original||64.89|
|IBM BladeCenter LS20||AMD Opteron dual core / 2.0||4||RedHat Enterprise Linux 4 / gcc||Original||57.13|
|IBM System x 3650||Intel Xeon dual-core (Woodcrest) / 3.0||8||RedHat Enterprise Linux 4 / Intel ICPC||Original||24.83|
|Intel X5355||Intel quad-core (Cloverton) / 2.66||16||RedHat Enterprise Linux 4 / Intel ICPC||Original||28.59|
|IBM BladeCenter QS20 (pre-GA)||Cell/B.E. / 2.4||1||Fedora Core 5 / gcc||Original||312.41/-|
|IBM BladeCenter QS20||Cell/B.E. / 3.2 (simulated)||1||Fedora Core 5 / gcc||Original||234.3/-|
|IBM BladeCenter QS20 (pre-GA)||Cell/B.E. / 2.4||1||Fedora Core 5 / gcc||Modified||51.46/-|
|IBM BladeCenter QS20||Cell/B.E. / 3.2 (simulated)||1||Fedora Core 5 / gcc||Modified||38.59/-|
|IBM BladeCenter QS20 (pre-GA)||Cell/B.E. / 2.4||1||Fedora Core 5 / xlC||Modified||4.2/9.9|
|IBM BladeCenter QS20||Cell/B.E. / 3.2 (simulated)||1||Fedora Core 5 / xlC||Modified||3.15/7.42|
As Table 4 shows, compared with more traditional x86 processors, the Cell/B.E. system is significantly more powerful when running this same code. This table also illustrates the effect of the optimizations in the XLC compiler compared to the performance of the same modified code on the Cell/B.E. platform compiled using the two different compilers, gcc and XLC.
Many other individuals contributed (both knowingly and unknowingly) to this piece of work. The authors wish to acknowledge their kind contributions. Without their assistance, this paper would never have been written.
So why should you read the original whitepaper? The original whitepaper combines the contents of this entire series -- everything's available now. The paper also provides a tidy intro to the Cell/B.E. architecture, and it explains why the processor is important, especially for compute-intensive financial market applications.
- Use an RSS
feed to request notification for the upcoming articles in this series. (Find out more about RSS feeds of developerWorks content.)
The whitepaper, "Porting
Financial Markets Applications to the Cell Broadband Engine Architecture" (alphaWorks, June 2007), this series is taken from.
"Introduction to the Cell Multiprocessor" (IBM Journal of Research and Development, 2005) provides 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.
"Porting practices: Compute-intensive applications" (developerWorks, June 2007) can help when you want to bring a compute-intensive application to the Cell/B.E. architecture
"Tech tips: SPU vector intrinsics at your fingertips" (developerWorks, May 2007) is a handy list to keep you on the right side of common Cell/B.E. SPU vector intrinsics (and was taken from a fuller article, "Programming high-performance applications on the Cell BE processor, Part 5").
"Cell Broadband Engine Architecture and its first implementation" (developerWorks, November 2005) provides an up-close look at the performance figures and characteristics of the first implementation.
The QuantLib project 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 then exported to different languages such as C#, Objective Caml, Java, Perl, Python, GNU R, Ruby, and Scheme.
The Mersenne-Twister is a very fast pseudo-random number-generating algorithm which uses memory quite efficiently and is has a far longer period and far higher order of equidistribution than any other implemented generators.
"Implementation of a Mixed-Precision in Solving Systems of Linear Equations on the CELL Processor" describes in detail the implementation of code to solve linear system of equations using Gaussian elimination in single precision with iterative refinement of the solution to the full double precision accuracy.
The Software Development Kit 2.1 Installation Guide Version 2.1 (PDF) will walk you through installation and configuration and many of the basics 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 get the requisite FC6 up and running and provide a quick reference to Cell/B.E. terminology.
- To learn more on Cell/B.E. programming, try the
- "Programming high-performance applications on the Cell/B.E. processor"
- "PS3 fab to lab"
- "The little broadband engine that could"
Get products and technologies
The OpenMP API, a portable, scalable model that gives shared-memory parallel programmers a simple and flexible interface for developing parallel applications, supports multi-platform shared-memory parallel programming in C/C++ and Fortran on all architectures, including Unix and Windows NT platforms.
Here is the centerpiece of Cell/B.E. development, the latest Cell/B.E. SDK release, version 2.1.
We mentioned the IBM XLC compiler for porting efforts -- it is optimized for the Cell/B.E. processor.
The developerWorks Cell Broadband Engine Resource Center is your clearinghouse for Cell/B.E.-related resources, downloads, and news.
- Participate in the discussion forum.
The Cell Broadband Engine Architecture forum is the place to get your technical questions about the processor answered. (Juicy problems and answers from the forums are rounded up periodically and highlighted in the blog series, "Forum watch.")
The Power Architecture blog provides news, downloads, instructional resources, and event notifications for Cell/B.E. and other Power Architecture-related technologies and is the home of two blog series -- "Forum watch" (Q&A roundup) and the "FixIt" technology updates.
This contact page will enable you to discuss customized Cell/B.E. processor solutions with an IBM rep.
John Easton has worked for IBM for 18 years in a variety of UNIX technical roles. He worked in Distributed Filesystems development in Austin during the development of the RS/6000 and holds several patents pertaining to security and distributed systems. From 1990 to 2002, he focused on high availability and clustering, becoming the worldwide technical support leader for these areas and part of the Poughkeepsie lab team responsible for architecting and developing the HACMP and HAGEO products. He designed carrier-grade Linux solutions for several major telecommunications companies and represented IBM to the Service Availability Forum. Since 2002, he has been part of IBM's Grid Computing organization and the senior grid architect for EMEA. He is responsible for designing and implementing grid solutions for major companies across Europe. He brings expertise from his previous role, designing mission-critical grid solutions and influencing IBM product strategy in these areas.
Ingo Meents joined IBM nine years ago and works currently as an IT Architect in IBM Global Engineering Solutions (GES). His current focus is to provide IBM customers with knowledge of the latest Cell/B.E. software technology by consulting, educating, briefing, and creating solutions for this platform. Before his work on the Cell/B.E. platform, he was lead architect for a modeling, simulation, and production planning solution used by the IBM 300mm semiconductor line in Fishkill. Starting as a research student at IBM, Ingo Meents received his doctor's degree from the University of Clausthal in 2001.
Olaf Stephan joined IBM in 1998 and works currently as an IT Specialist in IBM Global Engineering Solutions (GES). His focus is to provide IBM's customers with knowledge of the latest Cell/B.E. software technology by consulting, educating, briefing, and development for this platform. Prior to his work on the Cell/B.E. platform he has worked in the area data management, data warehousing, business intelligence, and data integration. Olaf holds a Masters degree in Electrical Engineering, specializing in Communications Technology, from the University of Applied Sciences, Koblenz, Germany.
Horst has more than 10 years experience in the application of simulation methods and the development of mathematical models in different areas. He is currently leading in IBM's Global Engineering Solutions (GES) division the development team of a simulation and planning solution which is used by the IBM's 300mm manufacturing site in Fishkill and external customers as well. Furthermore, he is the European subject matter expert for the GES supply chain offerings. In addition he gives regularly lectures at university in the filed of simulation and mathematical modeling and he is member of a standardization group concerning simulation and optimization.
Sei Kato is a researcher staff member of IBM Research, Tokyo Research Laboratory. He joined IBM in 2002 after receiving his PhD in Mathematical Science from the University of Tokyo. After joining IBM, he has worked on modeling and simulating the performance of Web system. His current studies are the speed-up of financial calculation and the large-scale traffic simulation.