I was at an NSF-sponsored Workshop on Emerging Technologies for Interconnects (WETI) last week that was attempting to frame important interconnect research directions. I encourage everyone to check out the talk slides; talk videos will also soon be posted. In the coming months, a detailed report will be written to capture the discussion. This post summarizes some personal take-home messages.
1. Applications of Photonics: An important conclusion in my view was that photonics offers little latency, energy, and bandwidth advantage for on-chip communication. Its primary advantage is for off-chip communication. It is also worthwhile to look at limited long-distance on-chip communication with photonics. For example, if a photonic signal has entered a chip, you might as well take the signal to a point near the destination, thus reducing the cost of global wire traversal. Nearly half the workshop focused on photonics; many of the challenges appeared to be at the device level.
2. Processing in Memory: Our group has some initial work on processing-in-memory (PIM) with 3D chip stacks. It was re-assuring to see that many people believe in PIM. Because it reduces communication distance, it is viewed as a vital ingredient in the march towards energy-efficient exascale computing. However, to distinguish such ideas from those in the 1990s, it is best to market them as "processing near memory". :-)
3. Micron HMC: The talk by Gurtej Sandhu of Micron had some great details on the Hybrid Memory Cube (HMC). An HMC-based system sees significant energy contributions from the DRAM arrays, the logic layer on the 3D stack, and the host interface (the memory controller on the processor). SerDes circuits account for 66% of the power in the logic layer.
4. Electrical Interconnect Scaling: Shekhar Borkar's talk was interesting as always. He reiterated that mesh NoCs are overkill and hierarchical buses are the way forward. The wire energy for a 16 mm traversal matches the energy cost per bit for a router; frequent routers therefore get in the way of energy efficiency. He pointed out that the NoC in the Intel 80-core Polaris contributed 28% to chip power because the computational units were so simple. The NoC in Intel's SCC chip consumes more power than the NoC in Polaris, but the overall contribution is lower (10%), because the cores are more beefy and realistic. In moving from 45 nm to 7 nm, compute energy will reduce by 6x; correspondingly, the electrical interconnect energy to travel a fixed length on-chip reduces by only 1.6x and the energy for off-chip interconnect reduces by less than 2x. So the communication energy bottleneck will grow, unless we can reduce communication and communication distances.
5. Miscellaneous: There was a buzz about near threshold computing (NTC). It appears to be one of the few big arrows left in the quiver for processor energy efficiency. It was also one of many techniques that Patrick Chiang mentioned for energy-efficient communication. He also talked about low-swing, transmission lines, and wireless interconnects. Pradip Bose's talk had lots of interesting power breakdowns, also showing trends for the IBM Power series.
Showing posts with label NoC. Show all posts
Showing posts with label NoC. Show all posts
Wednesday, February 8, 2012
Trip Report -- NSF Workshop -- WETI
Labels:
Computer Architecture,
Interconnects,
NoC,
Silicon Photonics
Saturday, February 5, 2011
Common Fallacies in NoC Papers
I am asked to review many NoC (network-on-chip) papers. In fact, I just got done reviewing my stack of papers for NOCS 2011. Many NoC papers continue to make assumptions that might have been fine in 2007, but are highly questionable in 2011. My primary concern is that most NoC papers over-state the importance of the network. This is often used to justify complex solutions. This is also used to justify a highly over-provisioned baseline. And many papers then introduce optimizations to reduce the area/power/complexity of the over-provisioned baseline. Both of these fallacies have resulted in many NoC papers with possibly limited shelf life.
The first mis-leading overstatement is this (and my own early papers have been guilty of this): "Intel's 80-core Polaris prototype attributes 28% of its power consumption to the on-chip network", and "MIT's Raw processor attributes 36% of its power to the network". Both processors are a few years old. Modern networks probably incorporate many recent power optimizations (clock gating, low-swing wiring, etc.) and locality optimizations (discussed next). In fact, Intel's latest many-core prototype (the 48-core Single Cloud Computer) attributes only 10% of chip power to the network. This dramatically changes my opinion on the kinds of network optimizations that I'd be willing to accept.
The second overstatement has to do with the extent of network traffic. Almost any high performance many-core processor will be organized as tiles. Each tile will have one or a few cores, private L1 and L2 caches, and a slice (bank) of a large shared L3. Many studies assume that data placement in the L3 is essentially random and a message on the network travels half-way across the chip on average. This is far from the truth. The L3 will be organized as an S-NUCA and OS-based first-touch page coloring can influence the cache bank that houses every page. A thread will access a large amount of private data, most of which will be housed in the local bank and can be serviced without network traversal. Even for shared data, assuming some degree of locality, data can be found relatively close by. Further, if the many-core processor executes several independent programs or virtual machines, most requests are serviced by a small collection of nearby tiles and long-range traversal on the network is only required when accessing a distant memory controller. We will shortly post a characterization of network traffic for the processor platform I describe above: for various benchmark suites, an injection rate and histogram of distance traveled. This will hopefully lead to a more meaningful synthetic network input than the most commonly used "uniform random".
With the above points considered, one would very likely design a baseline network that is very different from the plain vanilla mesh network. I would expect some kind of hierarchical network: perhaps a bus at the lowest level to connect a small cluster of cores and banks, perhaps a concentrated mesh, perhaps express channels. For those that haven't seen it, I highly recommend this thought-provoking talk by Shekhar Borkar, where he argues that buses should be the dominant component of an on-chip network. I highly doubt the need for large amounts of virtual channels, buffers, adaptive routing, etc. I'd go as far as to say that bufferless routing sounds like a great idea for most parts of the network. If most traffic is localized to the lowest level of the network hierarchy because threads find most of their data nearby, there is little inter-thread interference and there is no need for QoS mechanisms within the network.
In short, I feel the NoC community needs to start with highly localized network patterns and highly skinny networks, and identify the minimum amount of additional provisioning required to handle various common and pathological cases.
The first mis-leading overstatement is this (and my own early papers have been guilty of this): "Intel's 80-core Polaris prototype attributes 28% of its power consumption to the on-chip network", and "MIT's Raw processor attributes 36% of its power to the network". Both processors are a few years old. Modern networks probably incorporate many recent power optimizations (clock gating, low-swing wiring, etc.) and locality optimizations (discussed next). In fact, Intel's latest many-core prototype (the 48-core Single Cloud Computer) attributes only 10% of chip power to the network. This dramatically changes my opinion on the kinds of network optimizations that I'd be willing to accept.
The second overstatement has to do with the extent of network traffic. Almost any high performance many-core processor will be organized as tiles. Each tile will have one or a few cores, private L1 and L2 caches, and a slice (bank) of a large shared L3. Many studies assume that data placement in the L3 is essentially random and a message on the network travels half-way across the chip on average. This is far from the truth. The L3 will be organized as an S-NUCA and OS-based first-touch page coloring can influence the cache bank that houses every page. A thread will access a large amount of private data, most of which will be housed in the local bank and can be serviced without network traversal. Even for shared data, assuming some degree of locality, data can be found relatively close by. Further, if the many-core processor executes several independent programs or virtual machines, most requests are serviced by a small collection of nearby tiles and long-range traversal on the network is only required when accessing a distant memory controller. We will shortly post a characterization of network traffic for the processor platform I describe above: for various benchmark suites, an injection rate and histogram of distance traveled. This will hopefully lead to a more meaningful synthetic network input than the most commonly used "uniform random".
With the above points considered, one would very likely design a baseline network that is very different from the plain vanilla mesh network. I would expect some kind of hierarchical network: perhaps a bus at the lowest level to connect a small cluster of cores and banks, perhaps a concentrated mesh, perhaps express channels. For those that haven't seen it, I highly recommend this thought-provoking talk by Shekhar Borkar, where he argues that buses should be the dominant component of an on-chip network. I highly doubt the need for large amounts of virtual channels, buffers, adaptive routing, etc. I'd go as far as to say that bufferless routing sounds like a great idea for most parts of the network. If most traffic is localized to the lowest level of the network hierarchy because threads find most of their data nearby, there is little inter-thread interference and there is no need for QoS mechanisms within the network.
In short, I feel the NoC community needs to start with highly localized network patterns and highly skinny networks, and identify the minimum amount of additional provisioning required to handle various common and pathological cases.
Subscribe to:
Posts (Atom)