MATLAB : Committed to Excellent Algorithms
description
Transcript of MATLAB : Committed to Excellent Algorithms
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?