My research is focused largely on software performance. Programs use resources like time, memory, and energy, but we generally want programs to be as fast, small, and efficient as possible. My work on software performance ranges from techniques to help software developers and maintainers better understand the resources their programs use, to techniques that automatically make programs better. This summer, I hope to focus on building a tool that will help developers understand how resources are used during a program’s execution, and focus in on the parts of this program that are responsible for excessive resource use.
One important piece of hardware that helps programs run faster is a cache. Caches are much faster to access than your computer’s main memory, but they are also much smaller. To help speed up memory accesses, your processor keeps copies of recently-accessed memory in the cache. The hope is that these same memory locations are likely to be accessed again in the near future. Caches are a limited resource, and programs that use particular memory access patterns can run much slower because they do not make effective use of the cache. Ineffective cache use shows up in the cache miss rate, the percentage of accesses to memory that do not find a match in the cache and instead have to go out to main memory.
Different parts of a running program may do a good or bad job using the cache. The plotshows how cache miss rates can vary over a program’s run; the x-axis shows the number of instructions completed since the start of the program, and the y-axis shows the number of cache accesses per one million instructions at each point.
This plot raises a couple of interesting questions about the program. First, why does its use of the cache vary so much during its execution? Second, what is the program doing during the periods where there are more cache misses? Answering these two questions could help the developer change the program to make better use of the cache during these periods, improving overall performance.
This is just one illustrative example of what I would like our tool to do. Just as we can look at cache use over time, we could measure the rate at which a program completes instructions, sends bytes over a network, or uses energy. A tool that shows us these results, allows us to identify periods of interest, and then analyzes the results to better understand what the program was doing during these periods could be invaluable to developers who are trying to debug their program’s performance.
Because almost all of my research work requires C and C++, you will need to complete CSC 161 or an equivalent course to work in my lab this summer. The project I am planning to pursue this summer will draw on concepts from CSC 211 and CSC 213, but I expect many strong students could learn the relevant material during the summer. I also expect a substantial amount of work on a data visualization component of the project, so students who were in my special topics course on data visualization or have other experience working with D3 would be able to contribute. There are many other skills you could bring to the project, such as statistics coursework, or just experience tinkering around in C on side projects. Most importantly, you must be interested research and be willing to learn.
While a MAP lasts for ten weeks during the summer, you will need to put in some additional effort before and after the MAP. We will start a weekly discussion group sometime in March to cover topics that will help you prepare for work over the summer. This will require you to read a moderate amount of material on your own, along with a few small independent projects to familiarize yourself with the programming language(s), tools, and techniques we’ll need during the summer. During the summer you are expected to work 40 hours a week for ten weeks. We will work as a group to set regular working hours and meeting times. If your project is successful, we will target some sort of publication toward the end of the summer; that means you may be expected to put in some additional time to prepare a paper and/or poster.
Please complete all of the steps below to apply for a MAP:
If you have any questions or concerns about summer research or my application process, feel free to ask me via email, in the hall, or during office hours. You are welcome to drop by any time my door is open, or you can make an appointment if you have more questions that will take a longer time to answer.