Porting Financial Market Applications to the Cell ...cavazos/cisc879-spring2008/KanikS.pdf ·...

CISC 879 : Software Support for Multicore Architectures

Presented By: Kanik SemDept of Computer & Information Sciences

University of Delaware

Porting Financial Market Applications tothe Cell Broadband Engine Architecture

John Easton, Ingo Meents, Olaf Stephen, Horst Zisgen, Sei Kato


Outline

• Why Cell B.E. for financial markets?• Porting strategies for the Cell B.E. platform• Performance results• Mixed-precision workloads• Tying it all together• Conclusions


Why Cell B.E. for financial markets?

• Potential for dramatic impact on financialapplications

• Application codes ported to the Cell• Optimized codes to fully exploit Cell• Performance improvements of almost 40x


A description of the application

• Code used to price a European Option.• Model based on Monte Carlo simulation technique.• Need to generate a large number (200,000,000 in this case) of

uniform, pseudo-random numbers.• Using the random numbers generated, execute the financial

model.


Porting strategies for Cell

• Recompilation of existing code for Cell• XLC better than gcc

• Make some structural changes• Framework to start separate threads on each SPU.• Splitting RNG across all cores.

• Make functional changes to the code.• Re-engineered functions to exploit vectorization on SPU cores.


Analysis of the original code

%time Seconds Calls Function name 62.70 118.32 200000000 getRandom() 37.18 70.16 1 simulateEuropeanOptionValue()

0.14 0.27 1 hpcMonteCarlo::random() 0.00 0.00 2 hpcBlackScholes()

SDK for Cell provides optimized RNG.Can generate 64 number generators at once on Cellblade.Use gettimeofday() function.


Initial performance results

To run the performance tests, the following parameterswere used :

• Compiler used: spuxlc, ppuxlc

• Compiler optimization setting: -03 –qstrict

• Random-number generation method: sdk

• Precision: single

• Number of evaluations: 200,000,000



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

1 65.7 49.27 1 2 32.9 24.6 1.99

3 21.9 16.42 3 4 16.4 12.3 4

5 13.18 9.88 4.98

6 10.9 8.17 6.02 7 9.4 7.05 6.98

8 8.2 6.15 8.01 9 7.3 5.4 9

10 6.6 4.95 9.95 11 6 4.5 10.95

12 5.5 4.12 11.94

13 5.1 3.8 12.88 14 4.7 3.52 13.97

15 4.4 3.3 14.93 16 4.1 3.07 16.02




Double Precision

Organizations in financial markets require double-precisioncalculations.

Initial target marketplace for Cell does not need this.

Initial implementation of Cell provides limited double-precisionsupport in hardware

Single-precision Fully pipelinedDouble-precision Partially pipelined


Performance results

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

1 157.3 117.9 1

2 78.6 58.9 2

3 52.4 39.3 3

4 39.3 29.47 4

5 31.49 23.61 4.99

6 26.25 19.68 5.99

7 22.5 16.8 6.99

8 19.7 14.7 7.98

9 17.5 13.12 8.98

10 15.78 11.8 9.96

11 14.3 10.7 11

12 13.1 9.82 12

13 12.1 9.1 13

14 11.3 8.47 13.92

15 10.5 7.87 14.98

16 9.9 7.42 15.89


Mersenne-Twister

• Run time with Mersenne-Twister (without optimization): 5 sec• Run time with the Cell/B.E. SDK: 4.1 sec

Mechanisms to improve the performance still further :Optimize Mersenne-Twister code for threading framework.Rewrite the code to utilize the SIMD capabilities of SPUs.

Performance comparison between Cell/B.E. SDK and Mersenne -Twister random -number generators

Precision Runtime

(seconds) SDK

RNG (2.4Ghz)

Runtime

(seconds)

Mersenne -Twister RNG (2.4

GHz)

Runtime

(seconds)

Mersenne -Twister RNG 3.2

GHz (estimated)

Single 4.1 1.02 0.76

Double 9.9 2.47 1.85


Mixed-precision workloadsMixed-Precision:Only those parts that actually need double-precision arecalculated using double-precision.

Disadvantage:Makes for a slight increase in the programming effortneeded

Identify parts of code which use this sort of precision Make the appropriate changes to the code.

Advantage: Performance improvement.


Mixed-precision workloads

The two methods of applying mixed-precision to our codeare:

(1) Concatenating two single-precision random variables.

(2) Generate one single-precision random variable and thendoing a double-precision division.



# SPU CC_DP_MT CC_DP_SDK M_DP_MT SP_MT SP_SDK

1 40.33 40.33 45.76 12.01 11.16

2 20.33 20.33 22.88 6.06 5.70

3 13.56 13.56 15.26 4.05 3.80

4 10.17 10.17 11.44 3.04 2.85

5 8.13 8.13 9.16 2.43 2.29

6 6.78 6.78 7.64 2.03 1.91

7 5.82 5.82 6.55 1.75 1.64

8 5.09 5.09 5.75 1.53 1.44

9 4.53 4.52 5.11 1.36 1.28

10 4.08 4.08 4.60 1.22 1.15

11 3.70 3.70 4.18 1.11 1.05

12 3.40 3.39 3.84 1.02 0.96

13 3.14 3.14 3.54 0.94 0.89

14 2.92 2.92 3.29 0.88 0.83

15 2.72 2.72 3.07 0.82 0.78

16 2.52 2.53 2.88 0.77 0.73

• 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





Additional optimization techniques :

• Unrolling more parts of Mersenne-Twister RNG.

• Additional software pipelining by parallelizing computation.

• Introducing new variables to eliminate dependencies.

• Pre-calculating some items:a[0]=<something>;for (i=0;i<N;i++){sinf4(a[0]) ;sinf4(a[i+1));......}


Intel optimizations

• A “master” thread forks “slave” threads to perform RNG.• “master” thread part of the Cell/B.E. code that runs on PPU• “slave” threads parts that run on the SPUs.

Difference:• Work scheduled by the OpenMP runtime shares same cores as the

OS threads.• The SPUs on the Cell/B.E. version are not running the operating

system. This enables them to be used entirely to run the applicationcode.


Intel optimizations

System/CPU Operating System Compiler No. of Threads (Cores)

Speed (GHz) 1 2 4 8

x3550/3.0 Red Hat Linux Intel ICPC 31.76 15.9 8.46 -

x336 / 2.8 Red Hat Linux Intel ICPC 43.27 30.02 22.62 -

HS21 / 2.33 Fedora Core 6 gcc 43.38 21.74 10.88 8.26


Tying it all together


Future Work

Results achieved so far are on a system that many viewas being unsuitable for Financial Markets users.

• “Enhanced Double-Precision” version of the CellBroadband Engine technology.

• Systems based on Cell/B.E. technology are an excellentplatform for Financial Markets applications.


Getting the most performance out ofCell/B.E. technology

Offload as much of the computation onto the SPUs aspossible.

Write the SIMD code yourself rather than relying on thecompiler to do it.XLC provides “auto-SIMDize”This may not be a good approximation.

In certain situations, you might find that starting fromscratch is a much quicker way to implement applicationcode.


Conclusions

Reasons for general-purpose processors make up themajority of the computational infrastructures :

(1) Huge numbers of systems based on these processors.

(2) Large supply of professionals skilled, this leads tolower skills costs.

(3) A lot of application development tooling.

(4) The relatively “easy” code porting to these platforms.


Conclusions

“ESOTERIC” technologies: Offer high performance for their chip area. Consume much less power per computation.

Disadvantages:(1) Skills to program them are rare and, hence, expensive.(2) Lack of application development tooling.(3) The “porting” process is generally both slow and costly.


Conclusions

Advantages of Cell/B.E. technology:

(1) Consumes less power, space and cooling(2) High computational power.(3) Better data movement and manipulation abilities.(4) A number of strong customer proof points.(5) Support from key Independent Software Vendors(6) Results of experiments such as this one.


Questions….

Comments….

Caveats ….

Date post:	25-Mar-2020
Category:	Documents
Upload:	others
View:	2 times
Download:	0 times

Porting Financial Market Applications to the Cell ...cavazos/cisc879-spring2008/KanikS.pdf ·...

Documents