Some things will be very important in this discipline and especially in your career in computing. You must know how to compile bem a program, to execute it in a practical and automated way, to debug it, to know which part of it is slower and to have notions of parallelization.
This lab is based on GNU tools which are already installed on Linux but which can be installed on Windows and Macs as well.
You must answer these questions:
In the end, you should be able to use these tools and also differentiate performance gain alternatives obtained by algorithms and also by tools.
This Exercise is divided into several parts and the most important goal is that you understand the tools indicated or similar. These tools will be used in the next activities of the discipline.
One of the first MP3 compressors / decompressors created is called dist10, you should find a file named dist10.tar.gz on the internet and download it (in the tests below, focus only on the files inside the folder lsf / encoder). For testing, use a large .wav file, such as this
(you can use others if you want). The encoder needs the file in AIFF format, for this, use the command "sox heavydrum.wav heavydrum.aiff" to make the conversion.
Now follow the activities below, writing down the information and decisions you will need to make to make your report at the end.
To do the next activity you must understand the applications configure e make.
Include simple answers to your questions in your report:
Compile the program without any extra options for extra compilation. How long does it take to encode the file? See if the value changes using, separately, each of the optimizations -O0, -O1, -O2 -O3 (capital letter O followed by a number). Which one gave the best time? There are other optimizations that you can apply to the current processor, see the gcc by category optimizations -mtune
and see which ones apply to your processor. What are they for? Has the weather improved? Always describe your results in relation to the slowest. Attention: The O3 option will not always be better. Measure the compilation time of the options and the execution time and see the differences (indicate in the report time you will use in each case: real, user or system?)
Now it's time to try to understand the program a little (but not entirely). Use GDB to debug your program. Often, the GDB text mode interface makes debugging difficult, I recommend that you use a graphical viewer for GDB. A good viewer is DDD (just run ddd
on the command line). Some interesting GDB commands that you should know how to use: breakpoint, watchpoint, print, display, run, set args and help. Use GDB to run some parts of the program and try to understand the flow of information in it. Remember that the focus is to better understand the use of GDB. Search for tutorials on Google if you prefer. Here are 4 suggestions: 1, 2, 3 e 4.
You should know:
Using the sample file provided as input, use the debugger to find the vector's value off, at the end of the eleventh execution of the function window_subband. Put the answer in your report.
Where does your program spend the most time? use gprof to find out (see the gprof manual or tutorials 1 and / or 2). Indicate the two functions that spend the most time on your program in the report.
Challenge (optional): If you have to parallelize any part of a program, which part would you choose? How to scale parallelize the code? I suggest using OpenMP, see a brief presentation, a tutorial, the official website, use by GCC e GNU implementation of for. About the time of the parallel program. Was the result expected? Comment. To earn a bonus on the note, find some part of the program Imagemagick
that can be parallelized, parallelized, generate a patch and submit as contribution to the site. If you look at the list of authors of the OpenMP patches, you will see the names of several alumni in my disciplines.