1. Min Heap Update E.g. remove smallest item 1. Pop off top (smallest) 320 36 40 35 37 60 50
2. Move bottom (large) item to top

2. Min Heap Update E.g. remove smallest item
3. Compare to children; swap if necessary 50 20 36 40 35 37 60

3. Min Heap Update E.g. remove smallest item O(log N) levels20
4. Repeat for each level 50 36 40 35 37 60
O(log N) levels
 O(log N) work

4. BFS and Dijkstra Demo

5. Better than Dijkstra’s Algorithm?

6. Dijkstra: Not So Smart!
Why are we examining nodes in the wrong direction?
Wasted CPU time!

7. Ideas? Only look at nodes that take us closer to the destination?
distToDest(node) < distToDest (predecessor)
Too severe – can result in no path, or not shortest path

8. A* Algorithms Enhancements to Dijkstra’s algorithm
Use domain-specific heuristics
E.g. we are working in a map
Can estimate which graph nodes are closer vs. further from dest
Incorporate into the wavefront sorting/ordering
Look at the most promising partial solutions first
“Best-first search”

9. Can go around blockages (e.g. 401)
A* Search
Mostly searches in the right direction, but will explore some in other directions
Can go around blockages (e.g. 401)

10. A* Heuristics Sort wavefront by? Ideas? n2 bestTime = 45 s source dest
Estimate (heuristic)

11. A* Implementation We are changing the wavefront sorting
Not the bestTime found to a node from the source
That must be accurate (not a guess)
Or we wouldn’t know when we’ve found a better path to a node
struct WaveElemAstar {
Node *node;
int edgeID; // ID of edge used to reach this node
double travelTime; // Total travel time to reach node
double myGoodIdeaOfValueToSortOn; }

12. A* Demo

13. Milestone 3 Performance Tuning Tips

14. Speed Tuning
Algorithm
Data structures
Low level code

15. Debugging Algorithms Start with a very simple test case
Adjacent intersections!
Step / breakpoint code in debugger
Make sure it does what you expect!

16. Debugging Algorithms Try a slightly harder case
Two intersections apart
Step / breakpoint code in debugger again!
Make sure code behaving exactly as you expect

17. Graphics to Visualize Algorithm

18. Bigger Cases: Graphics Helps
Hard to see large amounts of data in debugger
Use graphics to animate / visualize
#define VISUALIZE // Comment out to turn off
while (wavefront.size() != 0) {
// Get id of node to evaluate …
#ifdef VISUALIZE
record_node_visited (node_id);
#endif
...
application.run ( …
// Can visualize nodes you explored with ezgl
Don’t leave visualization on in your final submission!

19. Measuring Where CPU Time Goes
Profiling Code
Measuring Where CPU Time Goes

20. My Code Is Too Slow – Why? Look at code  what O() is it? Loading:
O(N) unavoidable and OK
O(N2)  not good if N can get big
Look-ups
If you’ll do something N times, try to keep it O(1) or O(log N)

21. My Code is Complex! Can’t figure out O()
Or O() looks OK, but still not fast enough
Profile!
Measure where the time goes

22. Simple Profiling: Manual Random Sampling
Run the debugger
Stop it with Debug  Pause
Look at the subroutine and line where you paused
Examine the call stack to see how you got there
Continue execution with Debug  Continue
More time in a routine  higher probability of stopping there
Usually stop in same routine  found the problem

23. Detailed Profiling: gprof Tool
Randomly samples the function your program is in
~ every 1 ms
Also records how it got there (call stack / call graph)
Then summarizes the output for you
How is this random sampling done?
Program asks to be interrupted ~1000x / second by operating system
Each interrupt  record function you are in

24. gprof Tool: How to Use Compile your program with the right options
Select profile configuration or make CONF=profile
Adds –pg option to compiler  instruments exe
Turns off function inlining  all function calls exist  easier to interpret

25. gprof Tool: How to Use Run program normally
./mapper
Collects statistics, stores in big file (gmon.out)
Program runs only a little slower (~30%)
Run gprof to summarize / interpret output
gprof mapper > outfile.txt
Reads gmon.out, generates readable outfile.txt
Even better: can visualize (graphics)
gprof mapper gmon.out | gprof2dot . py -s | xdot -
ECE 297 Profiling Quick Start Guide

26. Example: Extract Negatives
#include <vector>
using namespace std;
vector<int> extract_negatives (vector<int>& numbers) {
vector<int> negatives;
int i = 0;
while(i < numbers.size()) {
if(numbers[i] < 0) {
negatives.push_back(numbers[i]);
numbers.erase(numbers.begin() + i);
} else {
i++; //Next element }
return negatives;
Takes 30 s when given an 800,000 element vector. Too slow  why?

27. Visualized Call Graph Extract negatives called once by main
Takes 71% of time
Type equation here.
push_back()
Estimated 37% of time
This is an over-estimate: sample-based profiling isn’t perfect
Erase called over 640,000 times
Takes 53% of time
 biggest problem