ECEn 424 Homework Set #9
Upload a pdf file containing your solutions to the problems below to
Learning Suite before 11:00pm on the assigned date.
- Problem 424-8:
Create a memory mountain for at least one machine that you have
access to. Click here to get a
tar file for code to compute the memory mountain. The code should
compile and run on most Linux and Macintosh systems. Look through
the code in mountain.c to see how it works. When you run the
program, it should create a "mountain.res" file of resulting
throughput values that you can examine. The tar file includes a
"mountain.xlsx" Excel file set up to compute the memory mountain
surface. On a machine with Excel (you can use the college machines
in the computer room), open the "mountain.res" file, then cut and
paste the values to the worksheet in "mountain.xlsv".
Write a paragraph about your results that answers the questions
below, along with any other observations you'd care to make.
- How do your results vary if you edit the Makefile and change
the optimization level that mountain.c is compiled with? Try a few
experiments and report on the differences.
- How does your memory mountain compare with the one in the
text from the Intel Core i7 Haswell? (Compare both overall shape and
actual throughput measures.)
- What information about your test system can be deduced from
the memory mountain? (Compare with information about the measured
system -- check /proc/cpuinfo on a Linux machine, for example.)
- Problem 7.8 from the text
- Problem 7.12
- Problem 424-9:
Let's try to construct an example where the actions of the
linker create an "insidious run-time bug" (p. 682). Start with the
code in this tar file. The
Makefile compiles files "intdblconf1.c" and "intdblconf2.c" to
produce the executable "intdblconf". As the file names suggest, the
two files have conflicting definitions for a particular variable,
declared in one file as an int and in the other as a double. Look
through the source code, see what it does, and what the output
means. Edit the source code and change the initialization of
variable x to experiment with different weak and strong symbol
scenarios. Try at least one additional computer platform if you can,
and experiment with different optimization levels in the
Makefile. Also, make particular note of warning or error messages
you get from the linker. Write a paragraph that summarizes what you
found. What is the nature of the insidious run-time bug you
discovered, and what is required to produce it? Does the linker
help us out in avoiding these kinds of problems with a suitable
warning message?
Clarifications
For problem 424-8, no source code is required in your submission, but you
should include a printout of the memory mountain (the graph from the
Excel spreadsheet) along with your written comments about that surface
and what you can deduce from it. Even though this version of the
memory mountain code makes repeated measurements of each data point,
the accuracy of the results can vary widely with the system load; try
to run it on a machine that is otherwise mostly idle. (Try running
"top" to check the load average and CPU-intensive processes that might
be running in the background.) Finally, you really should try this on
different types of machines if at all possible -- the differences in the
surface can be startling. Mention in your report if you made memory
mountains on multiple platforms.
No programming or source code is required for the problems
from the text.
Problem 7.8 in the text has a typo in the code in part A. Under Module
2, it should be "static int main=1;" not "static int main=1]".
For problem 7.12, Read section 7.7, including practice problems.
For problem 424-9, include source code and a screenshot of
the output that clearly shows one instance where the bug arises, and
explain the bug in your writeup.
It appears that you must make a slight modification to the memory
mountain code to get it to work on a Mac. As on the previous homework
assignment, you will need to edit the timer.c file (included in
mountain.tar). Simply insert the word "volatile" immediately after
"asm" in the access_counter function. With this fix, it is reported
that you can use higher levels of optimization, contrary to the
comments in timer.c.
Last updated 1 April 2019