The Process

From bare bones to finished product

The Steps

Programming Debugging Performance Tuning Optimization

Programming

To create a set of instructions for a piece of hardware to follow

Two broad categories: Low-level languages High-level languages

Low Level Languages

Have a limited amount of abstraction between the hardware and the programmer

Deal with registers, memory addresses, etc Are often limited to a small set of platforms due

to this Examples:

Machine Code Assembly C

High Level Languages

Are “abstract” Human readable Use objects, variables, arrays, etc

Suffer from “abstraction penalty” Execution types:

Interpreted (Java, Python, Ruby) Compiled (C, C++, practically everything else) Translated (Often translated to C)

Debugging

The act of taking something broken and trying desperately to make it work

Where the significant time in any project is spent

Necessary for both hardware and software sides

Hardware Debugging

FIGURE 17.1 Platform Debug Process

Software Debugging

Can the problem be lived with? Attempt to reproduce the problem Narrow the suspects down

Divide-and-conquer Use specific debugging tools in the right place

Can lead to “false positives” Not capable of catching everything

Debugging Techniques

Path tracing – printf (or equivalent) Breakpoints Stepping through Memory/core dumps

Performance Tuning

Assess the problem Measure the performance Identify bottlenecks Modify that part Measure the new performance

Do not get caught up in minutiae!!

Tuning

May take one of several forms Code optimization Caching Load balancing Parallelization

All are bottlenecks

Optimization

More important for embedded systems Focus on the limitations of the platform

Speed Power consumption Memory usage

Exist as tradeoffs Greater speed, higher memory usage Lower power consumption, slower processing

Problems

Tuning and optimization are in themselves bottlenecks – though in production, not performance

May introduce new bugs Often not “human readable” May affect ease of upgrading

Programming, Tuning and Optimization

Code first, then tune and optimize Unoptimized code is often easier to code and

debug than optimized code Get the major flaws out of the reasoning first

Be specific Power consumption needs to be limited

Be reasonable Idealized reality rarely exists