MATLAB : Committed to Excellent Algorithms

1© 2012 The MathWorks, Inc.

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

FeaturesQuality

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

DGETRSDGBTRSDGTTRSDPOTRSDPPTRSDPBTRSDPTTRSDSYTRSDSPTRS

11

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

Level of Control Feature

Simple gpuArray, maths, same syntax as MATLAB

Intermediate arrayfun(@fun, …)

Detailed Direct integration with CUDA kernels

12

Architecture

GPU

GPU Driver

Mathworks GPU Runtime CUDA Runtime

Memory Mgnt

General GPU infrastructure

Algorithms 3p alg libs

gpuArrayCUDAkernelarrayfun

MATLAB – GPU JIT Compiler

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?