Yale Patt, a well-known computer architect likes to call multi-core multi-nonsense. He believes that multi-core was the easy way out chosen by Intel/AMD architects to harness the increasing transistors. In his words, “multi-core is a solution looking for a problem.” Others argue that multi-core is in fact a large opportunity for us architects to innovate. I agree more with Yale (with reservations) that it started out as multi-nonsense.
I disagree with Yale because I don’t think the fundamental reason to do multicore was not because that single core was too complex. Perntium 4 was perhaps the most complex microprocessor every built, but it was delivered as product on schedule. What killed the single-core machines was the fact that increasing performance of a single core, while staying in a reasonable power budget, was becoming impossible. To use the spare transistors, Intel and AMD put an extra core down in Opteron and Pentium Dual Core for the first time. So yes, it was a solution looking for a problem. We threw these dual core chips out there hoping that programmers will figure out a way to harness them for performance.
As for multi-core being an opportunity, I think its a pessimist vs. an optimist argument. Any difficult problem can be perceived as an “opportunity” or a “problem.” I do however agree that multi-cores have once again ignited innovation in computer architecture, thus the net result is perhaps positive.
How has this impacted the design?
Interestingly, the fact that that multi-cores were not done for performance the first time, did make their design unbalanced. Initial multi-core chips were not suited to run multi-threaded workloads with very high communication latencies among cores. Intel Pentium-D used FSB for core-to-core communication. They had non-inclusive L2 caches which increased snoop penalties among cores. Anyways, we have come long ways from there.
How to fix multi-core?
I would argue that the best use of multi-cores is for parallel multi-threaded programs. Hence, architects MUST focus their attention on making parallel programming easier. This does require non-conventional thinking. It implies we can no longer design for existing workloads and produce bar charts with benchmark results. It sends down this fuzzy path where we have to interact with programmers and qualitatively argue what may work. I am debating that this non-scientific approach can lead to better results.
I would love to hear from programmers with parallel programming experience. Are there features you would like us architects to put? Will transactional memory really help? Faster atomic operations? lower migration costs?