High Performance Programming with C++

1. High Performance Programming with C++ Hafiza Rabbia Ibrahim July 25, 2011 R.Ibrahim (CE Master)

2. Outline • Motivation • Return Value Optimization (RVO) • Inlining • Standard Template Library (STL) • Constructor and Destructors • Virtual Functions • Coding Optimization R.Ibrahim (CE Master)

3. Motivation R.Ibrahim (CE Master)

4. Return Value Optimization (RVO) R.Ibrahim (CE Master)

5. Why ? “The optimization often performed by the compilers to speed up your source code by transferring it and eliminating object creation.” R.Ibrahim (CE Master)

6. For instance, let’s walk through a simple example of complex numbers: Without optimization, the compiler generated code for Complex _ Add() is: R.Ibrahim (CE Master)

7. The compiler can optimize the Complex _ Add( ) by eliminating the local object retVal and replacing it with __tempResult. This is RVO: R.Ibrahim (CE Master)

8. Execution time comparison R.Ibrahim (CE Master)

9. Is it mandatory? • NO! • The application of RVO is up to the discretion of compiler implementation. You need to consult your compiler documentation or experiment to find if and when RVO is applied. R.Ibrahim (CE Master)

10. INLINING R.Ibrahim (CE Master)

11. What we are avoiding: Method Invocation Costs R.Ibrahim (CE Master)

12. Why Inline? • most significant performance enhancement technique available in C++. Program’s Fast Path • the portion a program that supports the normal , error free, common usage cases of he program’s execution. • typically less than 10% of the program’s code lies on this fast path. Inlining and Fast Path “ Inlining allows us to remove calls from the fast path.” R.Ibrahim (CE Master)

13. Inlining Performance Story Performance of avoiding expensive method invocation Cross Call Optimization Performance R.Ibrahim (CE Master)

14. Performance gain of Avoiding method invocation • when outlined: 62 seconds execution time • wheninlined: 8 seconds execution time • Inlining provided here, 8x performance gain R.Ibrahim (CE Master)

15. Performance gain of Cross Call Optimization R.Ibrahim (CE Master)

16. Performance gain of Cross Call Optimization (cont.) If inlined: simple optimization and calculations If outlined: no one method optimization is possible, intra-method optimization is only possible R.Ibrahim (CE Master)

17. Why not Inline? If Inlining is that good, why don’t you inline everything? R.Ibrahim (CE Master)

18. Issues with Inlining • Size of program source code increases • Storage issues • multiple instances -> each has unique address • each has storage in cache -> decrease in cache size • capacity miss rate of cache • Degenerative characteristics • exponential code growth R.Ibrahim (CE Master)

19. Inlining A,B,C,D will increase the code size by more than 70k bytes i.e.; 37x increase. R.Ibrahim (CE Master)

20. When you should inline to be optimized? R.Ibrahim (CE Master)

21. How we are avoiding: Inlining Optimization Tricks When INLINE is not defined , the .h file will not include the inlined methods , but rather these methods will be included in the .c file, and the inline directive will be stripped from the front of each method. R.Ibrahim (CE Master)

22. R.Ibrahim (CE Master)

23. concluding words about Inlining • Inlining “might” improve the performance. • Inlining may backfire i.e.; increase the size of the code Be sure about the real cost of calls on your system before using Inlining! R.Ibrahim (CE Master)

24. Standard Template Library(STL) R.Ibrahim (CE Master)

25. Questions to be answered • Faced with a given computational task, what containers should I use? Are some better than others for a given scenario? • How good is the performance of the STL? Can I do better by rolling my own home-grown containers and algorithms? R.Ibrahim (CE Master)

26. Execution time Comparisons INSERTING AT THE FRONT R.Ibrahim (CE Master)

27. Execution time Comparisons (cont.) DELETING ELEMENTS AT THE FRONT R.Ibrahim (CE Master)

28. Execution time Comparisons (cont.) Container traversal speed R.Ibrahim (CE Master)

29. Can I do better? R.Ibrahim (CE Master)

30. Comparison STL speed to Home-grown code R.Ibrahim (CE Master)

31. Conclusions about STL performance • Outperforming the STL is possible. • Bend over backwards to concoct scenarios in which a home grownimplementation outperforms the STL. • Outperforming STL ,home grown implementation should havesomethingbetter that STL does NOT have! R.Ibrahim (CE Master)

32. Constructors and Destructors R.Ibrahim (CE Master)

33. Why this analysis? • The performance of constructors and destructors is often poor due to the fact that an object's constructor (destructor) may call the constructors (destructors) of member objects and parent objects. • This can result in constructors (destructors) that take a long time to execute, especially with objects in complex hierarchies or objects that contain several member objects. • Hence a Performance Hit! R.Ibrahim (CE Master)

34. Connection b/w cost of constructor/destructor and Inheritance based design • Encounter: Implementation of thread synchronization constructors • In multithreaded applications ,there should be thread synchronization to restrict concurrent access to shared resources • Thread synchronization constructs can be any of : • Semaphore • Mutex • Critical Section R.Ibrahim (CE Master)

35. Strategy: • Encapsulate the lock in an object e.g. MutexLock object • Let the constructor obtain the lock • Destructor will release the lock automatically (as it does for regular objects) • Compiler inserts a call to the lock destructor prior to each return statement • And the lock is always released! R.Ibrahim (CE Master)

36. Performance Comparison constructors destructor behaviour with Mutex in case of • Non-inherited object • inherited object R.Ibrahim (CE Master)

37. Lock class implementation R.Ibrahim (CE Master)

38. BaseLock class implementation This class is intended as a root class for the various lock classes that are expected to be derived from it. R.Ibrahim (CE Master)

39. Subclass of BaseLock: MutexLock class implementation LogSource object is meant to capture filename and source code line where the object was constructed. R.Ibrahim (CE Master)

40. MutexLock constructor R.Ibrahim (CE Master)

41. MutexLock Destructor R.Ibrahim (CE Master)

42. Non-inherited Mutex Object SimpleMutex object from a class containing acquire( ) and release( ) methods R.Ibrahim (CE Master)

43. Inherited Mutex Object replace SimpleMutex by DerivedMutex ( object of a derived class from BaseMutex) R.Ibrahim (CE Master)

44. Execution Time comparison R.Ibrahim (CE Master)

45. Concluding Remarks • Distinguish b/w over all computational cost, required cost, and computational penalty. • Eliminate the one which is not important by some other mechanism • Over all cost increases with the size of derivation tree. R.Ibrahim (CE Master)

46. VIRTUAL FUNCTIONS R.Ibrahim (CE Master)

47. Inflict on performance • Class with Virtual function -> virtual function table (vtbl) -> assigns each object a pointer -> vptr. Virtual functions seem to inflict a performance cost in several ways: • The vptr must be initialized in the constructor • VFs are called using pointer indirection, resulting a few extra instructions per method invocation. • Inlining is compile time decision. The compiler cannot inline VFs whose resolution takes place at run time. R.Ibrahim (CE Master)

48. Performance Comparison for virtual and Non-virtual methods • Creating virtual objects costs more than creating non-virtual objects, because the virtual function table must be initialized. • And it takes slightly longer to call virtual functions, because of the additional level of indirection. R.Ibrahim (CE Master)

49. Performance Comparison for virtual and Non-virtual methods (cont.) R.Ibrahim (CE Master)

50. Construction/destruction shows the performance penalty of initializing the virtual function table. • Virtual function invocation is slightly expensive than invoking a function through a function pointer : memory overhead. R.Ibrahim (CE Master)