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

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

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

BFS and Dijkstra Demo

Better than Dijkstra’s Algorithm?

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

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

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”

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)

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

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; }

A* Demo

Milestone 3 Performance Tuning Tips

Speed Tuning Algorithm Data structures Low level code

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

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

Graphics to Visualize Algorithm

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!

Measuring Where CPU Time Goes Profiling Code Measuring Where CPU Time Goes

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)

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

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

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

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

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

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?

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