This is the first of two equally-weighted assessed coursework exercises. Hand submit your solution via CATE.
SUSAN is an acronym for Smallest Univalue Segment Assimilating Nucleus. The SUSAN algorithms cover image noise filtering, edge finding and corner finding. In this exercise we will study edge detection. For more information about SUSAN see
http://www.fmrib.ox.ac.uk/~steve/susan/Simple edge detection algorithms work by differentiation in space, using a small local convolution filter. Unfortunately, this strategy works badly in the presence of noise, which is, of course, very common. SUSAN works on a different principle, ``univalue segments'': for each pixel in the image, find the contiguous, surrounding segment whose pixels that have the same value. The characteristics (eg size) of this ``Smallest Univalue Segment Assimilating Nucleus'' are strongly influenced by the presence of edges and corners.
Copy the source code directory tree to your own directory:
cd cp -r /homes/phjk/ToyPrograms/ACA05/Susan ./Now compile the susan.c program:
cd Susan makeNow you can run the program:
./susan.x86 Ins/input_large.pgm -e > Outs/large.pgmThis reads input from the file Ins/input_large.pgm, and writes its output to the Outs directory. Both input and output files are in PGM (Portable Gray Map) format (see ``man pgm''.
You have been provided with a selection of input files of various sizes:
input_small.pgm (76x95 pixels; from Susan distribution) input_large.pgm (384x288 pixels; from Susan distribution) Cupboard.pgm (1760x1168) ToySoldier.pgm (3072x2048)If you need a larger one, see /homes/phjk/ToyPrograms/ACA05/Susan_ExtraImages.
The makefile also builds a binary for execution using the SimpleScalar simulator. You can execute it by typing:
/homes/phjk/simplesim-3.0/sim-outorder ./susan.ss \ Ins/input_large.pgm -e >/dev/nullThis should take less than three minutes (80 seconds on a 3GHz Pentium 4).
Use the fastest machine you can find. On a 3GHz Pentium 4 each simulation run (for problem size 1) takes less than 1.5 minutes. Use the ``top'' command to make sure you're not sharing it.
The most important output from the simulator is ``sim_cycle'' - the total number of cycles to complete the run. It's often also useful to look at ``sim_IPC'', the instructions per cycle - provided you always execute the same number of instructions. The time taken to perform the simulation ``sim_elapsed_time'' simply tells you how the simulator took.
Other outputs from the simulator can be helpful in guiding your search - eg ``ruu_full'', the proportion of cycles when the RUU is full.
To do this you need to write a shell script. You might find the following Bash script useful:
#!/bin/sh -f for ((x=2; x <= 128 ; x *= 2)) do echo -n "ruu-size" $x " " /homes/phjk/simplesim-3.0/sim-outorder -ruu:size $x \ ./susan.ss Ins/input_large.pgm -e \ 2>&1 >/dev/null | grep sim_IPC doneThe output is delivered to the file ``results''. You can find this script in
scripts/vary_ruuSee also ``vary_lsq''.
Try using the gnuplot program. Run the script above, and save the output in a file ``table''. Type ``gnuplot''. Then, at its prompt type:
set logscale x 2 plot  'table' using 1:4 with linespointsTo save the plot as a postscript file, try:
set term postscript eps set output "psfile.ps" plot  'table' using 1:4 with linespointsTry ``help postscript'', ``help plot'' etc for further details.
Compile the application using the ``-S'' flag.
~phjk/simplescalar/bin/gcc -O3 -S susan.cThe assembler code generated by the compiler is delivered in ``susan.s''.
The compiler accepts many parameters to control optimisation. Try ``man gcc'' to read about them1. For example, ``-funroll-loops'' encourages the compiler to unroll loops:
~phjk/simplescalar/bin/gcc -O3 -funroll-loops susan.cDoes this improve the performance of the simulated machine? What happens to the IPC?
Paul Kelly, Imperial College London, 2005