Modern research in computer architecture has been developed far beyond the conventional textbook topics of processor microarchitectures and memory hierarchies, now expanding to a much more diverse range of novel areas. Computer architects can explore many promising directions to make exciting improvements. But on the other hand, new graduate students, as well as undergraduates who are interested in this area, may however become increasingly confused and hesitate when choosing their initial research directions. Not only does it take more time to adequately understand the background in each of these many new areas, but making a decision also gets harder. I have been often asked by students, “after reading the relevant papers, these several topics seem equally interesting to me; which one should I choose then?” Besides students, junior faculty members who are considering expanding their research scopes may also face the same issue.
Fortunately, there have already been many excellent posts in the SIGARCH blog series that make great introductions to various emerging topics, such as hardware security, machine learning for systems, quantum computing, cryptography acceleration, graphics, brain-computer interface, optoelectronics, approximate computing, in-sensor computing, and even space systems! This article, as a complement, assumes that you already have some sense about the basics in these areas, and focuses on discussing how to choose the most suitable topic among them to best fit your case. I will discuss several commonly asked questions. Please be warned that by no means does this article try to straightly give you a final answer. Every choice has its own pros and cons, and everyone is in a unique situation that should assess these factors differently. I will only show the tradeoffs and give some general advice, hopefully alleviating some confusion and anxiety. After all, making tradeoffs for specific scenarios is exactly the core philosophy of computer architecture, isn’t it?
Machine learning or not?
Needless to say, machine learning (ML) has been the hottest topic in almost all science and technology fields in the last decade, and computer architecture is no exception. Both systems for ML and ML for systems naturally become popular directions that attract many students. However, it does not necessarily mean these areas will be a good choice for you.
The first path, systems for ML, is still the highest priority in industry today. Every company is proposing its own ML-specialized chips and/or frameworks, and there is still a lot of work to be done to make them practical. Work in this area could draw the most attention and have high impacts. However, the bar for research novelty is also continuously raising. Simple neural networks are no longer considered new. Standard tiling/unrolling/pipelining/fusion optimizations, and even various sparsity techniques, have all been extensively studied. Today, people turn their eyes towards more challenging workloads, e.g., attention layers, graph neural networks, point clouds, and dynamic models like Mix-of-Experts. There are also growing focuses on large scopes and end-to-end applications, e.g., recommendation systems, robotics, autonomous vehicles and drones, and multi-tenant scenarios.
On the other hand, ML for systems seems to have more opportunities to be exploited, especially as better ML algorithms constantly emerge and may substitute traditional manually-designed heuristics. I personally have two tips here. First, applying ML to a system problem is not as simple as randomly plugging in an algorithm and pressing the bottom. A good case should connect the two in a synergic way, e.g., Paragon and Voyager. How should I map the system problem into a task that has known effective ML solutions? Which algorithm and representation should I use and why are they better than the alternatives? How to deal with the high computation and storage cost? Second, keep in mind that ML might not necessarily work better than traditional heuristics, so always compare with a strong baseline and include thorough ablation experiments. For example, database indexes are one of the very first data structures considered to use ML replacements, known as learned indexes. Despite many follow-up designs, there is still a debate about whether the ML approaches truly have advantages over traditional structures.
Emerging interdisciplinary topics or not?
Besides ML, many more application domains start to expect specialized hardware/software. Quantum, cryptography, genomics, and the list continues to grow. It is exciting to work on these emerging areas. Interdisciplinary topics apply computing techniques to real-world problems in other fields, and many of these problems could in turn inspire new innovations in computer systems. In another word, not only are we solving practical challenges, but also there exist many low-hanging fruits for research.
Nevertheless, many students are afraid of the additional interdisciplinary knowledge that must be learned, which seems to at least double the study workload. Indeed, there is a non-trivial amount of application background that you need to understand, e.g., quantum physics for quantum computing, computational biology for genome acceleration, abstract algebra and number theories for cryptography, etc. If you dislike physics, biology, or math, then you probably should skip. But also do not overestimate the difficulty. You are not asked to become an expert, but only need to understand the computational flow to start a system design. The algorithm details, such as why a crypto algorithm is proved to be secure, are not necessary to fully understand at the beginning, until the time you start to consider algorithm-system co-design!
Another note is that the so-called low-hanging fruits may not be of truly high values. Directly mapping the computation flow (e.g., crypto and genomic) to hardware may not always bring new and interesting architectural insights. Dealing with system challenges in a new paradigm (e.g., quantum) actually follows a retrospect of the traditional optimizations in many aspects. For example, the NTT operation in many crypto algorithms reassembles the well-known FFT kernel. You still need to sufficiently survey the prior arts, look for new motivations and opportunities, and come up with novel optimization techniques. Try to avoid annoying review questions like “the paper is naïve with little novelty” or “what you proposed has all been done in the 90’s, go check paper X, Y, Z!”
Last but not least, be sure to keep calm when encountering a new opportunity; it may or may not fit you. If it becomes a crowd field, you may not even be fast enough to grab the low-hanging fruits you see now! For this issue, you definitely should not miss this interesting piece!
Doing multiple projects in parallel?
Some students are worried about the high risk of betting on a single direction, and thus consider trying multiple things in parallel to see which one can eventually work out. However, the quality of your work in this case may not be as high as fully focusing on one project. In addition, it would take longer to finalize your work for a submission, and there could be other similar work getting out before yours and nullifying some of your new contributions. It is well known that batching, while beneficial for throughput, hurts latency, especially when the batched tasks differ significantly. Also remember, for a thesis, a coherent and in-depth series of work will be much more impressive than a set of incremental contributions in different areas.
My personal advice is to focus on a single problem if this is your first research attempt. If you also have other interests, feel free to partially participate in a few other projects to get some experience and contribute what you can do. You will still need to manage your time between your own responsible project and the other collaborations. But hopefully you only context switch your hands rather than your mind!
It is also usually not a good idea to frequently change topics. It is more than common in research to encounter difficulties and temporarily run out of ideas. Before giving up, what you should do is to have a solid analysis on why it does not work or why there is little room for improvements. For example, you can show that the workload is memory-bound so better accelerators will not help, or the processing units already reach 90% utilization so there is merely a 10% potential left. A negative result without a thorough analysis is not a sufficient excuse for changing projects.
To wrap up, choosing a suitable research direction is an important yet highly personalized issue. The best answer is not from other people, but needs yourself to try and experience. Evaluating the aforementioned tradeoffs could be your first lesson in computer architecture!
About the author: Mingyu Gao is an assistant professor at the Institute for Interdisciplinary Information Sciences (IIIS) at Tsinghua University. His research interests lie in the fields of computer architecture and systems, including efficient memory architectures, scalable acceleration for data processing, and hardware security.
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.
