Testing AMD's Bergamo: Zen 4c

Original Article ↗ Hacker News Discussion ↗

AMD’s Bergamo “Zen 4c” server chips, which pack over 100 compact x86 cores per socket, are prompting renewed debate over how far many‑core CPU designs can scale in practice. Commenters focus less on raw core count than on bottlenecks such as SRAM/cache area, memory latency, cache coherency, and the strong x86 memory model, arguing these may limit scalability more than transistor budgets. Several note that most software still struggles to exploit high core counts due to multithreading complexity, suggesting that architectural shifts (ARM, RISC‑V, GPUs, NIC‑offload, 3D-stacked cache) and new programming models may be as important as hardware advances.

Zen 4c / Bergamo Characteristics

  • Zen 4c cores have similar per-cycle performance to Zen 4 but:
    • Less L3 cache per core.
    • Lower maximum clock, especially vs desktop Ryzen; not much lower than dense server Zen 4.
    • Slightly better performance per watt is suggested, but magnitude is unclear.
  • Bergamo uses 8 compute chiplets; speculation/roadmap mention a follow-on part with 12 chiplets and 192 Zen 5c cores.

Caches, SRAM, and Coherency

  • SRAM (especially cache) is seen as the primary scaling bottleneck: more cores imply more cache area.
  • 3D V-Cache extends shared L3, but L1/L2 remain per core.
  • Chiplet-based designs can scale cores and cache capacity, but:
    • Cache coherency across many dies is complex.
    • NUMA “cliffs” and memory latency can dominate as core counts rise.

Memory Models: x86 vs ARM

  • x86 has a strong consistency model, making multithreaded programming easier but imposing higher synchronization and coherency costs.
  • ARM offers weaker guarantees; can scale better but demands more careful software.
  • Some argue these semantics may eventually limit how far x86 can scale in-package.

ISA and Decoder Complexity Debate

  • One view: ISA choice barely matters; x86 decode occupies a small die/power budget (single-digit percent).
  • Counterview: variable-length x86 instructions make wide, multi-instruction decode and branch prediction significantly more complex and power-hungry than fixed-width ARM/RISC-V.
  • There is discussion of uop caches, instruction density, and complex multiplexing logic; no consensus on how decisive this is for future many-core designs.

Many-Core Futures and Software Limits

  • Some see Bergamo-style “core spam” as the natural future: many simpler cores to hide memory latency, echoing earlier ideas like Sun Niagara and research projects.
  • Others stress single-thread performance remains crucial; in many real workloads, most cores sit idle.
  • Amdahl’s law and the difficulty of writing correct, scalable multithreaded code are repeatedly cited.
  • Modern languages (Go, Rust, functional / reactive approaches) help but do not solve parallelism for typical applications.
  • Removing bottlenecks like Python’s GIL is seen as necessary but far from sufficient for effective use of 100+ cores.

Networking, Caches, and Near-Memory Compute

  • Some speculate about “RAM-less” or RAM-minimized servers that keep hot code and state entirely in cache, streaming data from NIC to CPU and back.
  • Existing technologies (e.g., NIC-to-cache DMA, DPDK) already approximate “process in L3” models.
  • There is interest in pushing more compute to or near the NIC, but current solutions (e.g., FPGA-based smart NICs) are expensive and specialized.