4 ms·
>Make way for the 64-bit 128-core 1024gb RAM 8cm^2 SoC This is already happening? Intel Xeon Knights Landing already has an enormous 6.83cm^2 die size. It has
by n00b101 10y ago
>Make way for the 64-bit 128-core 1024gb RAM 8cm^2 SoC
This is already happening?
Intel Xeon Knights Landing already has an enormous 6.83cm^2 die size. It has 72 "cores," each of which has a 512-bit vector processor. In some sense, you could say that this chip has 9,216 "single precision cores." It also supports up to 384GB DDR4 RAM, which is not far from your 1024GB.
The term "core" is becoming vague, as NVIDIA refers to thousands of "CUDA cores" on its GPUs which are really vector processor elements.
China's Sunway SW26010 is also kind of a "SoC," 260 "cores" communicating via a Network-on-Chip interconnect. I think one could say that the Cell Broadband Engine processor had a similar design.
> make it practical and economical to make larger chips
I do wonder if die sizes can increase.
I'm not a hardware engineer, but my understanding is that latency is the main barrier to larger chips. The time it takes for a signal to propagate across a chip limits the clock frequency. One possibility is to replace the global synchronous clock design with an asynchronous chip design. However, from what I understand, this would make things worse because some form of synchronization is always needed - you could send back an "acknolwedge" message, but that would double the signal traffic.
On the other hand, supercomputers are regularly built with multi-socket systems and interconnects like QPI and PCIe between processors and nodes. It would seem logical to put multiple processors their interconnects on a single "SoC" and I don't know why that doesn't happen. Maybe it is because of error rates, as you say.
- pjc50 10y agoAsynchronous does not help you on latency at all - it's not the latency of the clock that matters. It's the data latency. This is already kind of crippling, as it takes hundreds of cycles to get anything from RAM if it's not in your cache. Only way to improve that is to make programming languages push either data locality or dataflow like designs, which may mean giving up or reimagining OO. Error rates (yield) are a serious problem, but if your design is uniform enough you can very well get away with just disabling bits. There's also a less obvious problem with on-chip variation (OCV) - some physical properties have a gradient across the chip. At runtime, there's a temperature gradient as well.
- api 10y agoOr... continuing with the BFC concept... make chips with monster caches or even with all SRAM running at core speed. That's not been done in a while.
- pjc50 10y agoCaches effectively are SRAM. It's inherently much less dense than DRAM; I had a quick look on Intel and the largest I could see was 37Mb of cache.
- n00b101 10y agoIt's not SRAM, but Kights Landing has 16GB of "MCDRAM" which is high bandwidth 3D-stacked DRAM. 400+GB/s throughput but latency is similar to conventional DRAM.
- deleted 10y ago[deleted]
- Dylan16807 10y agoLatency is not a problem. The recent huge chips from Intel serve as a perfectly good example. Haswell puts the cores and IO controllers on 1-2 ring busses. Knights Landing uses a mesh network. In each cycle, data only has to travel between neighboring nodes. A memory controller that's 4 hops away is barely noticeable.