1 / 29

Quantitative Basis for Designing Parallel Programs: A Performance Evaluation Approach

Explore optimization in parallel programming considering factors like execution time, scalability, efficiency, and costs using mathematical performance models. Learn about Amdahl's Law limitations, speedup metrics, efficiency calculations, and performance evaluation methods in this comprehensive guide.

carlalong
Download Presentation

Quantitative Basis for Designing Parallel Programs: A Performance Evaluation Approach

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Performance Measurement • Assignment? • Timing #include <sys/time.h> double When() { struct timeval tp; gettimeofday(&tp, NULL); return((double)tp.tv_sec + (double)tp.tv_usec * 1e-6); }

  2. Paper Schedule • 22 Students • 6 Days • Look at the schedule and email me your preference. Quickly.

  3. A Quantitative Basis for Design • Parallel programming is an optimization problem. • Must take into account several factors: • execution time • scalability • efficiency

  4. A Quantitative Basis for Design • Parallel programming is an optimization problem. • Must take into account several factors: • Also must take into account the costs: • memory requirements • implementation costs • maintenance costs etc.

  5. A Quantitative Basis for Design • Parallel programming is an optimization problem. • Must take into account several factors: • Also must take into account the costs: • Mathematical performance models are used to asses these costs and predict performance.

  6. Defining Performance • How do you define parallel performance? • What do you define it in terms of? • Consider • Distributed databases • Image processing pipeline • Nuclear weapons testbed

  7. Amdahl's Law • Every algorithm has a sequential component. • Sequential component limits speedup Maximum Speedup Sequential Component = 1/s = s

  8. Amdahl's Law s Speedup

  9. What's wrong? • Works fine for a given algorithm. • But what if we change the algorithm? • We may change algorithms to increase parallelism and thus eventually increase performance. • May introduce inefficiency

  10. Metrics for Performance • Speedup • Efficiency • Scalability • Others …………..

  11. Speedup What is Speed? Speed 1 What algorithm for Speed1? = S SpeedP What is the work performed? How much work?

  12. Two kinds of Speedup • Relative • Uses parallel algorithm on 1 processor • Most common • Absolute • Uses best known serial algorithm • Eliminates overheads in calculation.

  13. Speedup • Algorithm A • Serial execution time is 10 sec. • Parallel execution time is 2 sec. • Algorithm B • Serial execution time is 2 sec. • Parallel execution time is 1 sec. • What if I told you A = B?

  14. S = E p Efficiency The fraction of time a processor spends doing useful work

  15. Cost (Processor-Time Product) = C pT p = # processors p T = s E C

  16. Performance Measurement • Algorithm X achieved speedup of 10.8 on 12 processors. • What is wrong? • A single point of reference is not enough! • What about asymptotic analysis?

  17. Performance Measurement • There is not a perfect way to measure and report performance. • Wall clock time seems to be the best. • But how much work do you do? • Best Bet: • Develop a model that fits experimental results.

  18. Parallel Programming Steps • Develop algorithm • Develop a model to predict performance • If the performance looks ok then code • Check actual performance against model • Report the performance

  19. Performance Evaluation • Identify the data • Design the experiments to obtain the data • Report data

  20. Performance Evaluation • Identify the data • Execution time • Be sure to examine a range of data points • Design the experiments to obtain the data • Report data

  21. Performance Evaluation • Identify the data • Design the experiments to obtain the data • Make sure the experiment measures what you intend to measure. • Remember: Execution time is max time taken. • Repeat your experiments many times • Validate data by designing a model • Report data

  22. Performance Evaluation • Identify the data • Design the experiments to obtain the data • Report data • Report all information that affects execution • Results should be separate from Conclusions • Present the data in an easily understandable format.

  23. Finite Difference Example • Finite Difference Code • 512 x 512 x 5 Elements • 16 IBM RS6000 workstations • Connected via Ethernet

  24. Finite Difference Model • Execution Time • ExTime = (Tcomp + Tcomm)/P • Communication Time • Tcomm = 2*lat + 4*bw*n*z • Computation Time • Estimate using some sample runs

  25. Estimated Performance

  26. Finite Difference Example

  27. What was wrong? • Ethernet • Change the computation of Tcomm • Reduce the bandwith • Tcomm = 2*lat + 4*bw*n*z*P/2

  28. Finite Difference Example

More Related