The results you get will depend on the machine you use to run the code. They may also vary from run to run on the same machine. If you find the results interesting on one machine, you might try running again on a different one to see if they are even qualitatively simliar. For example, you might run on attu and then on your own machine.
Worse1, some of the results will probably make no sense to you. In my experience, that's almost always what happens when you measure things, and is one of the reasons to do this homework. You think you know how your system is behaving, but when you measure it, it's doing something else.
When measurements don't make sense, it could be that there's a bug in the measurement code and so we're not measuring what we thought we were. It could mean that the thing we're measuring doesn't behave like the simplified mental abstraction we've constructed for it. Figuring out why measurements are what they are is often quite hard. No one is asking you to do that for this homework. (But, who knows, this might be so interesting that you choose to spend some leisure time trying to figure it out...) You most likely will never be sure if the results you see in this assignment are "right" or not.
attu.cs.washington.edu:/cse/courses/cse451/20au/hw0/to some machine on which you'd like to run the measurements. Any machine with a reasonable C build environment could potentially work. (I've tried only Linux machines, though.)
less /proc/cpuinfo. Information about the CPU on your system will be printed. That might be useful in understanding results later (but only if you get really interested in this and try to explain the results).
gcc *.cdoesn't succeed, but comes kind of close. That's intentional. Fix whatever is wrong so you can build the app. (This is a build error, not a program coding error. You don't have to edit any files to fix the issue.)
The obvious goal of this assignment has to do with operation costs and measurement. There is another goal, though, which is working with things that are incompletely, and perhaps poorly, understood. This assignment is intentionally vague in a lot of ways, for one thing. That's a tiny step into the uncertain if you're used to the polished, detailed assignments we usually like to give in CSE. The code doesn't even build, and I'm not telling you why. (Please don't tell each other why either.)
There will likely be times during the projects that occupy the rest of the quarter when you feel that you don't know what is going on. That's okay. You'll overcome it.
If you find yourself harboring an uneasy feeling that something is terribly wrong, how can it matter if an operation takes 6 μsec or 24 μsec, it's only a constant factor, you're completely correct, in a way. That a system that runs applications 4 times faster than another is somehow better, though, is completely correct as well.
1 By "worse" I actually mean "Better yet!"