MATLAB : Committed to Excellent Algorithms

1. MATLAB: Committed to Excellent Algorithms Jos Martin jos.martin@mathworks.co.uk

2. Overview • Setting up the problem – what are we trying to build? • What have we got to work with? • How are we going to do • Design • Implementation • Testing

3. What do you want MATLAB to do? MATLAB … Do the bits of my work I don’t really want to do – please! MATLAB is a place where we build tools to help you do your work

4. Development trade-off Time Features Quality

5. Attributes of good software • Bug-free, Fast, Accurate, Usable • Accurate • Usable • Bug-free • Fast

6. The Martin Software Engineering Principle Frequently Jos is surprisingly stupid

7. A software engineering methodology • What and Why? • How? (for the user) • How? (for the software system) • How? (no seriously, I do actually need to write some code!) • Did I make a mistake? (in my own code) • Did I make a mistake? (in my team) • Did I make a mistake? (in any code from MathWorks) • …

8. A software engineering methodology • Requirements • Functional Design • Function prototypes, object interface, API, etc. • Graphical User Interfaces • Architecture • Modularity • Components • Reuse

9. Real situation: Make MATLAB use GPU’s • Requirements • Things the GPU is good at – maths, what else? • All GPU’s? Some subset? • Functional Design • The Nike Approach – Just Do It … • Explicit opt-in

10. “Simple to use” vs. “Lots of control” • Solve A*x = b for unknown x • Simple x = A\b • Lots of control DGETRS DGBTRS DGTTRS DPOTRS DPPTRS DPBTRS DPTTRS DSYTRS DSPTRS

11. “Simple to use” vs. “Lots of control”

12. Architecture CUDAkernel gpuArray arrayfun MATLAB – GPU JIT Compiler General GPU infrastructure Memory Mgnt Algorithms 3p alg libs Mathworks GPU Runtime CUDA Runtime GPU Driver GPU

13. Implementation • Remember Martin’s Software Engineering Principle • You can only remember 3 ± 4 things at any one time! • Keep ALL code as simple as possible • Always use standard patterns • Don’t describe what you are doing, describe why • Some details • McCabe complexity < 15 • Compiler warning free, close to lint-free • Short functions (less than 2 screens) • Lots of green

14. The Ronseal™ Guarantee • Everything Does exactly what it says on the tin™ ® • Functions, variables, classes, macros, packages, files, error messages, …

15. Review Everything

16. Principle of Least Surprise

17. Performance • Make sure the code works before tuning for performance • Identify what, if anything, needs optimization (Profiler) • Less that 4% of a program usually accounts for more than 50% of its runtime • Be careful, tuning for performance usually decreases the readability and maintainability of code • Always consider performance at the design stage

18. Testing • Test at every possible level • Individual code units • Local systems • Full system integration • Stress tests for scalability • Interactive (both competent and new user) • Automated testing • Aspire to full case coverage • Push for 100% code coverage • Performance

19. Maintenance • Keep your code base clean • Don’t let it acquire cruft[1] • Always remove all extraneous code • Always leave it better than you found it • Refactor as needed • Costly but nearly always the right thing to do [1] Cruft is jargon for software or hardware that is of poor quality

20. What to do when it doesn’t work! • Does it always fail? • Fix it in the right place in the architecture • Sporadic failures? • Oups!

21. Questions?