Communications of the ACM
Who Needs Massively Multi-Core?
A startup recently crammed 100 cores on a single chip. While that prototype is not ready for general use, Andy Bechtolsheim (co-founder of Sun Microsystems) recently predicted that, in about a decade, 64 cores will be the norm, but that each core will have no more memory available to it than today.
This begs the question, why? Who needs massively multi-core? Who are we building this for?
Mobile devices and laptops? Minimizing power consumption is far more important there. Desktop and gaming boxes? Most desktop applications barely tax the systems we have, and gaming systems need specialized GPUs, not CPUs. Servers? The massive clusters used by Google, Yahoo, and Microsoft crave memory and network bandwidth, not more CPUs.
Adding to the difficulty, we currently have no idea how to use all these cores, especially in mobile or the desktop. Current programming models simply cannot find the parallelism and there is considerable doubt that they ever will. On servers, there may be some hope that carefully constructed independent loads could balance demands on bandwidth, memory, I/O, and CPU, but, even there, finding enough exclusively CPU-heavy workloads to use all those cores seems unlikely.
Rather than have more cores, it seems that most of us would rather have lower power consumption and more memory. In mobile devices, we want them to go for days without recharge. On the desktop and data center, we want lower power bills and fast access to data. We do not want more CPUs.
Segmentation of the industry seems to have caused us to be blind to what we should build. CPU manufacturers are pushing their piece in isolation, ignoring the big picture of what consumers want. Consumers do not need more CPUs. Consumers do not need massively multi-core.
For a radically different look at massively multi-core, please see also my earlier post, "What to do with those idle cores?"
Comments
Mohamed Zahran
Having more cores per chip does not necessarily means we need to use them all. Here is a possible scenario. When the temperature of a core increases, usually the system will lower frequency and/or voltage of that core in order to avoid hotspots. We will feel a slowdown. On the other hand if we have idle cores, we can "migrate" the thread from the heated core to that idle one.
Ricardo Cillo
Maybe not 64 cores, but Intel had increased energy efficiency with the dual core tecnology. Lower clocks generate less heat.
But sometimes it looks like they forgot that some problems are intrinsically sequential.
gene tani
I think the STM vs. message passing vs lock/semaphore/mutex debate is pretty unsettled. There's the STM (haskell, clojure) vs. erlang /scala message passing camps:
http://www.tbray.org/ongoing/What/Technology/Concurrency/
http://www.sauria.com/blog/2009/10/05/the-cambrian-period-of-concurrency/
http://groups.google.com/group/clojure/browse_thread/thread/5c7a962cc72c1fe7?hl=en
http://wiki.jvmlangsummit.com/pdf/36_Click_fastbcs.pdf
Displaying all 3 comments