I have been fortunate enough to have many helpful senior students and two wonderful advisors to learn from throughout my PhD. Now as a senior PhD student myself, I have identified some lessons that proved most valuable as well as common mistakes made by younger graduate students. While these may be common knowledge, I am documenting these tips here to pass on some of our collectively learned lessons to future graduate students.

1. Learn to read a paper efficiently.
Fifty years of architecture research has produced a venerable but sizeable collection of research literature, growing by almost 200+ papers a year just from the top four conferences. To make good progress as we wade through the ocean of related work, it is important to read papers efficiently. Here is a useful three-pass technique for reading papers efficiently. For me, reading a paper involves finding an answer to these questions (inspired by grant writing tips):

• What is the problem that the paper is trying to solve?
• Why is the problem relevant?
• What is the insight that drives the solution proposed by the paper?
• What are the trade-offs of the proposed solution?
• How have the authors evaluated the solution?
• What is one good trait in the paper (problem, solution, evaluation, presentation)?

2. Know when to stop reading papers.
Whenever one begins a new project, it is easy to fall into the trap of endlessly reading paper after paper of related work. While surveying related literature is essential, it tends to yield diminishing returns after a certain point.  it is equally important to get one’s feet wet and actually start working on a project. There will be gaps in one’s knowledge but any critical gaps can be filled when that information is actually needed. After all, a graduate student is expected to be an information producer and not just a consumer.

3. Join or start a reading group.
One way of being social is to participate in a reading group, which is a group of students that meet regularly to discuss an interesting paper (old or new) related to a particular area (e.g., architecture). In each meeting, one of the members is responsible for leading the discussion while the others are expected to have read the paper so as to contribute to the discussion. Through reading groups, one is forced to read papers outside of one’s particular niche. Ph.D. graduates often end up working in an area outside of the focus of their thesis. Thus, being exposed to a wide variety of topics is extremely useful. Group discussions also help bring out multiple perspectives into the same paper.

4. Use appropriate evaluation methodologies.
There is no one size fits all when it comes to evaluation methodologies. Always select an appropriate methodology by taking into account development time, simulation speed and accuracy of results. There are three broad types of evaluation methodologies. Analytical modelling involves building mathematical models of the area of interest. At early stages of a project, it may be more useful to build simple mathematical models to get a broad sense of the efficacy of a research idea. Popular analytical models include the Roofline Model, Little’s law, Bottleneck analysis and others. Trace-based simulation involves using simulators that read in instruction or memory accesses sequences (traces) to provide reasonable estimates of runtime. Finally, execution-based simulators model hardware behavior at a cycle granularity. While such simulators offer the most accurate results, they also require the most development time as well as simulation time. As such, they may be overkill for simpler experiments. Hence, it is good to be familiar with different evaluation methodologies and use the right one at the right time.

5. Work on real systems.
Although simulators are becoming more sophisticated, there is no substitute for working on real systems. This involves prototyping ideas in the linux kernel, modifying device drivers, building FPGA-based systems or taping out chips. Looking at real systems gives us an idea of the complexity and robustness of industrial-strength solutions. This also forces us to confront the practical limitations of our ideas. The rise of open-source hardware along with existing open-source software has made it easy to work on real-world operating systems, compilers, CPUs and GPUs.

6. Spend time improving your programming skills.
New computer architecture graduates may not already be good software engineers as computer architecture attracts students with backgrounds in hardware as well. However, PhD-level architecture research typically involves writing a lot of code as part of simulators, operating systems or benchmarks. Hence, it is worth spending some time early in the graduate lifecycle to improve one’s programming skills. Here are some handy resources:
Data Structures, Complexity Theory, Design Patterns, Code Style, Git/Mercurial, Pointers.

7. Use microbenchmarks wisely.
Microbenchmarks are simple and self-contained programs written to achieve a specific outcome. Microbenchmarks are immensely useful for preliminary exploration as well as sanity checking. An example is a program that can deterministically generate  ~100K TLB misses on every execution. Our example microbenchmark can validate a TLB simulator by comparing simulator-reported misses with microbenchmark-generated misses. Being simpler and more easily understood than full-fledged benchmarks, they can be used for initial evaluation to get results that demonstrate general trends. However, microbenchmarks should not be relied upon for any meaningful evaluation, particularly they should not be used as a proxy for real applications.

8. Create talks/posters/paper drafts to get early feedback.
Once we start plugging away at implementation work, we sometimes lose track of the big research picture and instead simply generate a lot of experimental results. It is important to analyze these results in the context of the overall project. Then, crafting a talk or poster even with little to no results forces us to present our ideas in actual words and images. Different presentation media make us think about our research differently and thus refine our story. By presenting our posters and talks to other researchers, we get timely feedback that can help set the direction of our project.

9. Care for your mental and physical well-being and maintain a support system.
The typical PhD lifetime is long years of hard work with a few triumphant occasions such as paper acceptances mixed in. Remember that graduate school is a marathon and not a sprint. Hence, it is important to care for one’s overall health by getting enough sleep, having a healthy diet and spending time on exercise and hobbies. More importantly, graduate school is the first time many of us struggle academically or feel unproductive which may lead to mental health issues. Just remember that you are not alone in facing these issues and it is okay to ask for help. Most schools offer free or subsidized mental health resources. Furthermore, try to build and subsequently maintain a strong support structure for yourself by nurturing personal relationships with family and friends. Be social with your peers and almost never say no to going out for lunch, attending practice talks and other such activities.

Acknowledgements
I thank Prof. Mark Hill, Lena Olson and Prof. Jason Lowe-Power for help improving this document. For teaching me these lessons in the first place, I am grateful to Prof. Mark Hill, Prof. Michael Swift, Prof. David Wood, Lena Olson, Jason Lowe-Power, Nilay Vaish, Jayneel Gandhi, Hongil Yoon, Rathijit Sen, Gokul Ravi, Marc Orr, Muhammad Shoaib, Joel Hestness, Prof. Tony Nowatzki, Newsha Ardalani, Vijay Thiruvengadam, Vinay Gangadhar and many others whom I encountered in graduate school.

About the author: Swapnil Haria is a 5th-year PhD Candidate at the University of Wisconsin-Madison, advised by Mark Hill and Michael Swift. His research is focused on hardware and software support for persistent memory.

Disclaimer: These posts are written by individual contributors to share their thoughts on the Computer Architecture Today blog for the benefit of the community. Any views or opinions represented in this blog are personal, belong solely to the blog author and do not represent those of ACM SIGARCH or its parent organization, ACM.