April 11

Mostly working on code this week. Things are moving along. We have almost all of the major components in place and functioning.

Tim: Wrote the performance-measure code for the UNIX getrusage() system call, which counts page faults, swaps, signals, and other OS-maintained information. Most of the framework for the SGI hardware measures (instructions, cycles, flops, etc.) is written, but there's a little more code to be written.

Also, improved the library in a couple of ways. I fixed the output so that it conforms to our file format specification. I changed the timer from 32 bits to 64 (2^32 nanoseconds = not very long). I rearranged some code to make it more portable. I intend to document the code with lots of comments for the programmer who needs to port it.

Rob: My work this week has centered around completing the parser for the application. This was one area where prior work from the demo could not be used since the demo version made no attempt at a real parser. This was completed on Thursday, at which time we were to have completed enough of the project to be able to demonstrate the application displaying events from a sample log file. The display portion has not been written yet. My time was absorbed completely in finishing the parser, but I hope to have the display working by Tuesday. This will require a good amount of work from myself, Liusong, and Tiger. Their availability is at present unknown.

I've also begun adding functionality related to loading a file into the viewer application. For example, the profile panel formerly used a set list of parameters for demonstration purposes. Now the loader routine substitutes the list of recorded counters from the log file into the chooser box.

On an unrelated project I discovered the wonders of javadoc, which offers the ability to keep source and documentation consistent as well as producing highly readable documentation that is in a familiar form for most java programmers. I'm slowly encoding doc comments into the code, primarily for my own use. I'm not yet prepared to advocate this as a group wide effort due to the known phenominon that adding great new tools often doesn't improve efficiency immediately. It works for me and anyone else inclined to use it. If not, it works just fine as regular comments as well.

Still left to do:

EventSequences must permit arbitrary indexing. Now we only have forward iterators which always begin at the beginning of the sequence.

Events and states must be drawable on the EventSequencePanels.

The legend panel must be written to at minimum display the color to event/state type mappings, and preferably permit chaning them as well.

Printing needs to be completed. Tiger and Liusong have worked on this, and the results look promising (to me, at least).

Events and States buttons need to be made independent again.

We need a second Indicator in the event window to provide for defining a time period. The defined time period would then be used to generate the data for the profile panel.

In other words, there's plenty to do, now we need to do it.

Tiger:

Liusong: Technical manual writing. Reading code.

Xiao: this week i changed the basic design about how to dump events into the logfile. originally we dumped the buffer in each process into the logfile; but we later found that it required a lot of syncronization operations among processors and would greatly affect the performance of the user program. So we decided to throw away the code we already had. Now i am going to dump each processor's events into its own logfile. And after the whole process is done and merge them together into the logfile we want. so i am implementing the code now.