Chocolate Bar!

luqili

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!

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

• 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

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!

Profiling Code

Measuring Where CPU Time Goes

My Code Is Too Slow – Why?

• Look at code what O() is it?– Loading:

• O(N) usually 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

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

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

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

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

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