Seyed Masoud Hosseini · Overview · Study log · Ideas · Transcript · RSS feed

Parallel Computing & CUDA · Lecture 18 of 19 · 1:11:48

Lecture 18: Hardware Specialization

Stanford CS149 I Parallel Computing I 2023 I Lecture 18 - Hardware Specialization on YouTube

Study guide

What this lecture covers

This lecture asks why modern computing is energy constrained and what hardware designers do about it. It builds on the previous lecture's discussion of heterogeneity, moving from data-parallel processors like GPUs toward hardware that is specialized for a single application. The lecture explains why general-purpose CPUs spend most of their energy on overhead rather than computation, then surveys the spectrum of specialized hardware, from DSPs and ASICs to FPGAs, and shows how much energy efficiency each buys you and what programmability you give up.

The second half introduces Spatial, a hardware-description language for building accelerators, and walks through a dot-product example to show how tiling, parallelism and pipelining are expressed explicitly. It closes by connecting these ideas to flash attention, showing how a streaming execution model can get similar benefits without hand-fusing kernels. After watching, you should be able to explain why specialization saves energy and describe the tradeoffs between CPU, GPU, DSP, FPGA and ASIC design points.

Key ideas

  • Denard scaling ended: transistors used to shrink and use less power each generation; now more transistors mean more power, so energy efficiency, not raw transistor count, limits performance.
  • Energy = power × time: with power roughly fixed, improving performance requires improving energy efficiency per operation, which means reducing overhead.
  • Instruction overhead dominates: in a typical CPU instruction, only a small fraction of energy (the lecture cites around 6%) goes to the actual arithmetic; the rest goes to fetching, decoding, dependency checking and data movement.
  • SIMD amortizes overhead: wider SIMD spreads fixed per-instruction overhead across more data elements, but going too wide risks poor utilization when data parallelism runs out.
  • ASICs trade flexibility for efficiency: a fixed-function ASIC (the lecture's example is an FFT design) can be roughly 100x more energy efficient and 1000x denser in chip area than a CPU, at the cost of only running one algorithm and taking a long time to design.
  • FPGAs sit in the middle: configurable logic blocks (lookup tables plus registers) combined with hard macro blocks for memory and multiplication give programmable hardware that is denser and more efficient than a CPU but less efficient than an ASIC.
  • Spatial exposes hardware directly: it is a domain-specific language, embedded in Scala, for writing accelerators using explicit memory hierarchies and two kinds of parallelism: independent (map-style) and dependent (pipelined).
  • Streaming avoids materialization: connecting kernels with FIFOs instead of writing intermediate results to memory lets a compiler fuse computation automatically, similar in spirit to what flash attention achieves by hand.

Walkthrough

Why computing is energy constrained (0:05)

The lecture opens by connecting back to the prior discussion of heterogeneous computing and data parallelism on GPUs. It introduces the energy equation (energy equals power times time) and explains that because Denard scaling ended roughly a decade before this lecture, adding transistors now increases power dissipation instead of coming for free. Since power is effectively capped across supercomputers, data centers, and battery- and fan-less mobile devices, improving performance requires cutting the energy spent per operation, and the way to do that is specialization.

Why CPUs waste energy per instruction (5:12)

The lecture breaks down where energy goes when a CPU executes something like a multiply-add: most of it is spent reading the instruction, decoding it, checking dependencies, checking resource availability, fetching operands, and moving data through caches, with only a small slice going to the actual arithmetic. SIMD helps by amortizing this overhead across more data elements at once, but a class discussion notes that making SIMD units too wide raises peak throughput while lowering average utilization, since applications may not have enough parallel data to keep all the lanes busy. A study of H.264 video encoding is used to show that even SIMD-friendly workloads leave a large share of energy going to non-computation overhead.

ASICs, DSPs and dedicated accelerators (10:18)

Using a 40-nanometer study, the lecture compares a general-purpose CPU (an Intel Core i7) against an ASIC built for a specific algorithm like FFT, finding roughly a 1000x improvement in chip-area efficiency and 100x in energy efficiency for the ASIC. The tradeoff is that an ASIC only runs one algorithm and can take many months to design, which only makes sense for algorithms important enough to justify the investment. DSPs are presented as a middle ground: complex instructions and addressing modes tuned for signal-processing algorithms like FFT and filtering, at the cost of needing low-level, hand-written code since compilers cannot easily target such complex instruction sets. The lecture also mentions Anton, a specialized molecular-dynamics accelerator built by D. E. Shaw, and Google's Tensor Processing Unit, which specializes in dense (and later sparse) matrix multiplication for machine learning.

FPGAs: configurable logic between ASIC and CPU (17:25)

Field-programmable gate arrays are introduced as a way to get programmable hardware that is still much more efficient than a CPU. Configurable logic blocks use lookup tables to implement arbitrary boolean functions of a small number of inputs, combined with registers for storage; these blocks can be cascaded to build larger functions. Modern FPGAs add hard macro blocks for memory and multiplication (DSP blocks) alongside the configurable logic, because building everything from lookup tables carries too much connection and implementation overhead. The lecture notes that FPGA resources are available both in university labs and through cloud services such as Amazon EC2.

The efficiency-programmability spectrum (21:28)

The lecture lays out a spectrum: CPU, GPU, domain-specific compute (like a machine learning accelerator programmable via PyTorch or TensorFlow), DSP, FPGA, and ASIC, arguing that moving right buys more energy efficiency at the cost of needing more specialized programming skill, more design effort and more money. A class discussion touches on why GPUs have absorbed some tensor-core specialization and why DSPs can look more efficient than GPUs for signal-processing-specific work even though GPUs are more general.

Programming accelerators with Spatial (28:33)

The lecture contrasts traditional hardware design (Verilog or VHDL at the register-transfer level) and high-level synthesis (writing C and relying on a compiler, aided by pragmas) with Spatial, a language designed for performance-oriented programmers who already think in terms of parallelism and locality. Spatial exposes explicit memory templates (SRAM, DRAM, registers, FIFOs, line buffers) and two kinds of parallel patterns: independent parallelism (for each, similar to map) and dependent, pipelined parallelism. A worked dot-product example shows loading tiles from DRAM into on-chip SRAM, reducing within a tile using a parallel multiply-and-reduction tree, and reducing across tiles, with design parameters controlling tile size, parallelism factor and whether stages are pipelined. Pipelining requires double buffering so a later stage can read data a prior stage already produced, and the compiler automatically handles memory banking needed to support the requested parallelism.

Streaming execution and flash attention (52:57)

The lecture connects Spatial's streaming model to flash attention, explaining that flash attention avoids materializing the full attention matrix by tiling and fusing computation, which reduces memory bandwidth. It shows that Spatial's streaming execution, where producer and consumer for each loops run concurrently connected by a FIFO, can get similar benefits without hand-writing a fused kernel: for example, computing softmax's exponential and row-sum steps as two loops connected by a FIFO instead of materializing an entire row. The FIFO must be able to hold a full row's worth of data, which is itself a limitation that flash attention's algorithmic reordering can further reduce. The lecture closes by summarizing that acceleration can yield 100x to 1000x energy efficiency gains, and that designing accelerators is fundamentally about understanding an application's parallelism and locality, then explicitly defining the resources and memory hierarchy to exploit them.

Before you watch

  • Be comfortable with the course's treatment of data-parallel execution and SIMD, since this lecture builds directly on the previous lecture about heterogeneous computing and GPUs.
  • Some familiarity with basic digital logic (lookup tables, registers) will help the FPGA section make sense.
  • Recall how flash attention avoids materializing the full attention matrix; the lecture assumes you already understand that optimization.

Check your understanding

  1. Why did the end of Denard scaling change how computer architects think about performance?
  2. In the energy breakdown of a CPU instruction, what consumes most of the energy, and how does specialization reduce it?
  3. What do you gain and lose by moving from a CPU to a DSP, an FPGA, or an ASIC for a given application?
  4. In the Spatial dot-product example, what is the purpose of tiling data from DRAM into on-chip SRAM before computing?
  5. How does a streaming execution model with FIFOs achieve some of the same benefits as flash attention's fused kernel?

From the YouTube description

Energy-efficient computing, motivation for heterogeneous processing, fixed-function processing, FPGAs, mobile SoCs

To follow along with the course, visit the course website:
https://gfxcourses.stanford.edu/cs149/fall23/

Kayvon Fatahalian
Associate Professor of Computer Science, Stanford University
https://graphics.stanford.edu/~kayvonf/

Kunle Olukotun
Cadence Design Systems Professor, Professor of Electrical Engineering and of Computer Science, Stanford University
https://engineering.stanford.edu/people/oyekunle-olukotun

Learn more about the online course and how to enroll: https://online.stanford.edu/courses/cs149-parallel-computing

To view all online courses and programs offered by Stanford, visit: https://online.stanford.edu/

← Lecture 17: Transactional Memory 2 · Lecture 19: Accessing Memory + Course Wrap Up →