2 ms·

TL;DR it’s dead in the sense, we’re falling short of doubling the transistor count every 18-24 months. That said, in terms of horizontal expansion (tripling or

TL;DR it’s dead in the sense, we’re falling short of doubling the transistor count every 18-24 months. That said, in terms of horizontal expansion (tripling or quadrupling the number of computational cores), surely the main challenge must be the lack of bandwidth to the memory to power such insane data transfer rates. You could of course dedicate some amount of memory to each compute node, then the problem is one of quickly splitting the workload into chunks and sending them their separate way with no need to move them around. In a way, LLM and neural networks do function that way. Maybe it is time to build hardware that maps 1:1 to the software architecture.

sheepscreek 2y ago
I always like to check my assumptions, here is what ChatGPT said of the above: Yes, there is truth to that argument—both in the limitations it describes and the vision it hints at. Let’s break it down: ⸻ 1. Bandwidth Bottleneck with Horizontal Scaling • True: As you scale out the number of computational cores (SMs in NVIDIA GPUs, for example), the global memory bandwidth becomes a bottleneck unless it scales proportionally. • GDDR6, HBM, and even on-package memory (e.g. Apple’s M-series) are attempts to address this. • Still, there’s a ceiling: latency and contention start dominating. • Problem: Many workloads, especially in ML, are memory-bound rather than compute-bound. Doubling cores doesn’t help if data can’t be fed fast enough. ⸻ 2. Local Memory per Compute Unit • True and Already Happening: Architectures are increasingly moving toward giving compute units local memory: • NVIDIA’s SMs have shared memory (very fast, but small). • AMD’s Infinity Cache, or on-chip memory on M1/M2, is another example. • TPUs and custom ASICs use SRAM close to the compute logic for matrix multiplies. • This is reminiscent of scratchpad memory in SIMD systems or old-school Cell processors. ⸻ 3. Workload Partitioning and Data Locality • Critical Insight: Yes, mapping data locality to compute locality is the key. • LLMs and other neural nets are mostly large tensor operations. • These can be tiled and distributed to cores with minimal inter-core communication if partitioned right. • This is why hardware-software co-design is becoming more important: • NVIDIA’s Tensor Cores and transformer engine • Google’s TPU with XLA compiler • Apple’s use of unified memory for CPU, GPU, and ML cores ⸻ 4. Hardware Matching Software Architectures • Emerging Trend: We are already seeing this: • LLM accelerators (e.g. Groq, Tenstorrent, Cerebras) aim to align hardware with transformer-like workloads. • Neuromorphic chips and systolic arrays are trying to escape the Von Neumann bottleneck by mimicking data flow instead of instruction flow. • Vision: Instead of generic ALUs doing many different things, you have domain-specific architectures (DSAs) optimized for matrix math, attention, etc. ⸻ Conclusion You’re touching on a real and current transition in hardware design: as Moore’s Law slows and workloads become increasingly specialized (especially ML/AI), the bottlenecks shift from FLOPS to memory bandwidth, latency, and data movement. Yes, scaling horizontally is increasingly limited by data movement costs, and yes, future architectures will (and already do) look more like the software they’re meant to run. Would you like a more technical breakdown of how LLM workloads are actually split across GPU memory hierarchies or how specific hardware like Cerebras or TPUs tackle this?

sheepscreek 2y ago

I always like to check my assumptions, here is what ChatGPT said of the above: Yes, there is truth to that argument—both in the limitations it describes and the vision it hints at. Let’s break it down: ⸻ 1. Bandwidth Bottleneck with Horizontal Scaling • True: As you scale out the number of computational cores (SMs in NVIDIA GPUs, for example), the global memory bandwidth becomes a bottleneck unless it scales proportionally. • GDDR6, HBM, and even on-package memory (e.g. Apple’s M-series) are attempts to address this. • Still, there’s a ceiling: latency and contention start dominating. • Problem: Many workloads, especially in ML, are memory-bound rather than compute-bound. Doubling cores doesn’t help if data can’t be fed fast enough. ⸻ 2. Local Memory per Compute Unit • True and Already Happening: Architectures are increasingly moving toward giving compute units local memory: • NVIDIA’s SMs have shared memory (very fast, but small). • AMD’s Infinity Cache, or on-chip memory on M1/M2, is another example. • TPUs and custom ASICs use SRAM close to the compute logic for matrix multiplies. • This is reminiscent of scratchpad memory in SIMD systems or old-school Cell processors. ⸻ 3. Workload Partitioning and Data Locality • Critical Insight: Yes, mapping data locality to compute locality is the key. • LLMs and other neural nets are mostly large tensor operations. • These can be tiled and distributed to cores with minimal inter-core communication if partitioned right. • This is why hardware-software co-design is becoming more important: • NVIDIA’s Tensor Cores and transformer engine • Google’s TPU with XLA compiler • Apple’s use of unified memory for CPU, GPU, and ML cores ⸻ 4. Hardware Matching Software Architectures • Emerging Trend: We are already seeing this: • LLM accelerators (e.g. Groq, Tenstorrent, Cerebras) aim to align hardware with transformer-like workloads. • Neuromorphic chips and systolic arrays are trying to escape the Von Neumann bottleneck by mimicking data flow instead of instruction flow. • Vision: Instead of generic ALUs doing many different things, you have domain-specific architectures (DSAs) optimized for matrix math, attention, etc. ⸻ Conclusion You’re touching on a real and current transition in hardware design: as Moore’s Law slows and workloads become increasingly specialized (especially ML/AI), the bottlenecks shift from FLOPS to memory bandwidth, latency, and data movement. Yes, scaling horizontally is increasingly limited by data movement costs, and yes, future architectures will (and already do) look more like the software they’re meant to run. Would you like a more technical breakdown of how LLM workloads are actually split across GPU memory hierarchies or how specific hardware like Cerebras or TPUs tackle this?