1. Chocolate Bar! luqili

2. Milestone 3 Speed 11% of final mark 7%: path quality and speed –Some cleverness required for full marks –Implement some A* techniques to pass hardest speed tests –Read up online Milestone 4 (another 11% of mark) –Find a good path to connect M intersections Courier company –Will have a CPU time limit –Will benefit from fast path-finding algorithms A good milestone 3 implementation will help you!

3. Milestone 3 Quality & speed: 7% –Need some A* for full speed marks –But not all portions best solved with A* Think about when to use what algorithm And how to extend what you saw in class User Interface: 4% –Make it usable –What would you want in directions? –How would you want to type commands / locations? –Try it on a friend or family member! –Lots of ideas in m3 handout Don’t need to implement them all

4. Suggestion: Type commands in console Print directions to console And draw path in graphics Hit “Proceed” to return control to console –Can enter next command

5. Milestone 3 User Interface Sounds a bit clunky! –Yes, but easier –Late in course: will learn multi-threading Lets a program do 2 things at once E.g. read commands and re-draw Bonus only!

6. Profiling Code Measuring Where CPU Time Goes

7. My Code Is Too Slow – Why? Look at code  what O() is it? –Loading: O(N) usually unavoidable and OK O(N 2 )  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)

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

9. 1. Overall Time Measurement Use the linux time command Type time, then regular program and arguments > time mapper /cad2/ece297s/public/maps/toronto.bin > 17.4u 0.0s 0:17.4... u  user time  time CPU was busy on your code s  system time  operating system time due to your program last number  wall clock time  how long you waited Can rigorously measure the CPU impact of changes

10. 2. Simple Profiling: Manual Random Sampling 1.Run the debugger 2.Stop it with Debug  Pause 3.Look at the subroutine and line where you paused 4.Examine the call stack to see how you got there 5.Continue execution with Debug  Continue More CPU time in a routine  higher probability of stopping there Repeat several times and find you’re in the same routine  you’ve found the problem

11. 3. Detailed Profiling: gprof Tool gprof tool –Randomly samples the function your program is in ~ every 10 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 ~100x / second by operating system –Each time it is interrupted, it records function it is in

12. gprof Tool: How to Use 1.Compile your program with the right options –Add –pg option to compiler  instruments exe –Specify –g option  need symbol table to know which function is at what memory address –Optimization? –Yes: want to speed up release build: -O2 g++ -pg –g –O2 … -o myProg.exe NetBeans: can make a Profile Configuration by copying Release Config and adding –g –pg Sometimes turn off function inlining to make profiling output easier to understand

13. gprof Tool: How to Use 2.Run program normally –myProg.exe arg1 … –Collects statistics, stores in gmon.out –Program runs only a little slower (~30%) 3.Run gprof to summarize / interpret output –gprof myProg.exe > outfile.txt –Reads gmon.out, generates readable outfile.txt