Pete's Log: Multithreading in the commercial world
Entry #1160, (Coding, Hacking, & CS stuff)(posted when I was 23 years old.)
Dr Freeh likes messing with my head. At this point, I'm considering it a good thing.
I was encouraged to devote some time to perusing relevant literature in hardware multithreading, with a particular focus on what interesting open issues there are for us OS types to look into. So I've been doing that. Preliminary results seem to indicate that little has been published about issues surrounding the interaction of the MTA and the OS. This is somewhat encouraging, because it means this is likely a field that can provide me with plenty of research to do.
Dr Freeh agrees with that to an extent. He decided to mess with me, though, by taking a pessimistic approach to the situation. There may be a good reason, he argues, for why so little seems to have been done in this area. It could be that people have tried to do this work, but failed because there is no good solution. Or it could be that nobody has done this work because nobody cares. The latter scenario is particularly frightening. After all, I care.
So my newest task is to prove that this is something worth caring about. I learned long ago that "This is cool" is not a valid argument for graduate level research. In fact, Dr Freeh is very market driven. Not in a sense that he wants to make money off this research, but in the sense that he wants this research to apply to the mainstream. As OS people, we should not hinder our own success by targetting a platform that will never be used. It will be difficult enough to convince people our OS ideas are worthy of acceptance if they apply to real situations. Why should anyone take us seriously if we target an architectural concept that may never become more than a collection of abstract research projects or worse yet die out alltogether?
So now I need to find evidence that hardware multithreading is a trend that will be around for a while. As frustrating as I want to find this situation, I really am pretty glad for it. I should be forced to justify what I want to do. Eventually I will have to, so I might as well begin now. So what have I found so far? The results are mixed.
First, a brief summary of MTA pros and cons. The big pros: cheap context switches, easy facility for masking latency. Cons: more cache conflicts, increased memory bandwidth utilization, issues in memory protection models, lack of software support. Is multithreading worth our while? I honestly don't know right now. It's a question I need to answer for myself sometime really soon. There's various ways by which I hope to come to an answer to that question, and one of them is looking at how much interest there is in MTAs these days.
First, there's the academic world. How much is multithreading being looked into these days? Multithreading seemed a big deal at one point. It seems that MTAs were of great interest in the late 80s and early 90s, and most of the papers I've found seem to be from that time frame. There is at least some active work still going on, though. A couple searches on citeseer seems to indicate that within the past few years there have been at least some publications related to multithreading. One area in multithreading that seems to be getting particular attention is Simultaneous Multithreading. So the academics haven't given up on multithreading yet.
More important, in my opinion at least, is the commercial world. What use, if any, is currently being made of hardware multithreading? Well, the most obvious answer is probably the Tera MTA (well, now known as the Cray MTA). They seem to have managed to justify work on this architecture for more than a decade now. Of course, I don't think they've yet proven the commercial viability of their MTA, but their continued presence gives me some hope. It will be interesting to see what happens to them.
While reading up on Simultaneous multithreading I discovered that Compaq had in late 1999 announced that they were going to use simultaneous multithreading in the Alpha. Given the current status of Alpha, I'm not sure how much this means, but the fact that a company was considering using an MTA technology in a general purpose processor is cool.
IBM actually released a multithreaded PowerPC processor (the RS64 IV) in the fourth quarter of 2000. The processor is used only in commercial servers, so when designing the chip, IBM carefully considered what kind of workload they expected the processor to see and chose a multithreaded design based on those considerations. The interface presented to software is of a multiprocessor system. Minimal changes were needed to the OS in order to make it treat each thread like a processor, and no changes were required to userlevel code. The RS64 IV only supports two threads, but based on their results, IBM claims that the implementation of multithreading they added to their chip yielded, in comparison to other techniques, a good ratio of performance cost to implementation gain. I need to figure out how well this chip did on the market. But it is encouraging to see that a big company implemented multithreading on a chip they released to market.
I also found a paper on dynamic multithreading which was coauthored by somebody at Intel. So I looked around the Intel research web page and found their Microprocessor Research Lab page. One group in this lab is looking into advanced concepts to incorporate into future generation IA-32 and IA-64 designs. The first project they list is "Multithread Microarchitecture" and they state they are researching "various flavors of multithreading," including simultaneous and dynamic. So that's encouraging too.
Another thing worth considering is that from talking with Arun I've heard that multithreading might make a lot of sense in a QCA architecture. So there may be future use for MTA research.
One thing I've noticed is that a lot of the multithreading work from a decade ago was coming from a parallel perspective, where systems would consist of multiple nodes, each of which was an MTA. The more recent work seems to look at multithreading as a means of improving single processor efficiency. The older work seemed more interested in providing new programming models, while the recent seems to try to support the current programming models without too much modification.
I gots to think about this stuff some more. We'll see what happens ...