Living in a Parallel World

1. Living in a Parallel World David Norfolk Practice Leader, Development and Governance Bloor Research email: david.norfolk@bloorresearch.com

2. Agenda • Overview • Thinking Parallel • Some scenarios • Getting tooled up • Knowing what is going on • Thinking out of the box • Messages to take away There will be time at the end for questions …and I’m happy to take interruptions, if I can deal with them quickly But don’t ask me for multi-threaded C++ code!

3. Overview I • Thinking Parallel • for multicore computers • think many — not 2,4,8 processors • not trivial • Get good tools and training • so you can really visualise what is going on

4. Overview II • Know what is going on • Baseline before • Measure after • Visual map showing bottlenecks • Thinking out of the box • do unlimited processors let you do things you couldn’t do before? • and, which processors?

5. Thinking Parallel • Think 1024-way • Don’t build in scalability limits • Don’t rely on the compiler • Your “hints” might be wrong • Good practice helps • Small cohesive components with low coupling

6. Thinking anti-parallel • Forget hype • Lots of 1-processor apps around • Migrating legacy might be harder than writing new apps • Regression testing • Think about what might go wrong • before you meet it in production • But it might not go wrong • Don’t panic!

7. Bad scenario I • Unhappy customers • New PCs, slower apps • New PCs all multicore • Comparatively slower processors • Comparing to when each new generation of PCs ran faster • Will people blame their own buying choices? • No! • They’ll blame you!

8. Bad scenario II • Strange bugs, odd performance issues • …but only under heavy load • Deadlock • Race conditions • Works OK in test • or after unhappy users go home • But you can’t reproduce the problem easily • Makes it hard to debug!

9. Bad scenario III • If you can’t cope with multicore, there are people who will • …or claim to • If they can’t, there may be no-one left to point this out • IT doesn’t always have a huge amount of cred with the business • You can’t afford not to have a good multicore story

10. It’s not all bad! • Multicore is here to stay • so “thinking parallel” isn’t going to be obsolete any time soon • Parallel processing allows computer power to increase • for richer application user experiences • But perhaps orchestrate multicore-enabled services? • Do you all need to code?

11. Positive scenario • Multicore making the infeasible, feasible • e.g. processing large datasets • Using parallel-enabled utilities • Although there’s no free lunch • Particular workloads • Program changes • Algorithm tuning

12. Opportunities • Exploit the multicore machines you have already • Lower power costs • Better utilisation • “Green computing” card • Scalability • Just add another processor • Richer user experiences • both for games and business

13. Take control • Take control of the multicore issue before bad things happen • Sell management on opportunities • efficient electricity usage • green credentials • a better business-user experience • Get training and get tools • Worth repeating

14. Get tooled up I • Plenty of vendors selling tools • Worth listening • …but there’s only so much a tool can do • Parallel processing is often non-intuitive • Fertile opportunity for bugs • Programs don’t behave as well as you expect

15. Get tooled up II • Use tools • Don’t just buy shelfware or comfortware • You want pictures • not just words/numbers • Get visualisation tools • …as well as coding tools • Try to avoid coding parallel from scratch • …it’s hard

16. Visualise • Visualise what’s going on • Baseline on legacy before migrating • How will you know problems are real? • Test on before migrating • On multicore • on single processor too • Under load

17. Really visualise! • Pictures of process flow • See patches of serialisation • Introduce end-to-end user experience monitoring • In production • Discover problems early • Work on real problems • Don’t optimise for the sake of it

18. Think out of the box • What can I do with unlimited processors? • Specialised functions? • Schedule work around other processors? • Simulate legacy environments? • But don’t re-invent the wheel • Look at mainframes for ideas perhaps…

19. Explore parallel • Utilities/services/platforms • Pervasive DataRush • Ingres VectorWise • Don’t just think PC CPU • Graphics co-processors • Multiprocessor mainframes • ZiiP and ZaaP • Job scheduler • Multicore architectures are an opportunity not a problem!

20. Messages to take away I • Think Parallel • …but don’t panic about it • Get training • It’s not trivial • think “many processors” • Good practice helps • small, loosely coupled, cohesive components • don’t force serialisation

21. Messages to take away II • Use tools to visualise flow • don’t rely on intuition! • Use tools to help you code • coding from scratch will be hard work and error-prone • you can’t just rely on the compiler

22. Messages to take away III • Visualise • to know what’s going on • Baseline performance • on serial architectures before migrating to multicore • Test performance • not just on multicore • and test under load • Prioritise • direct resources to where you have real problems

23. Messages to take away IV • It’s an opportunity, stupid! • think parallel “out of the box” • think “many” • Buy or orchestrate multicore-enabled services/utilities • so you don’t have to code it • Don’t limit yourself • …by thinking of only one processing stream, one processor

24. Goodbyee… • Feel free to contact me • David Norfolk, Practice Leader, Development & Governance, Bloor Research • david.norfolk@bloorresearch.com • Some further reading • www.it-analysis.com/enterprise/technology/content.php?cid=10464 • www.it-analysis.com/business/change/content.php?cid=10156 • www.it-analysis.com/blogs/The_Norfolk_Punt/2010/1/abstractions.html • Any questions?