How might software development have unfolded if CPU speeds were 20x slower?

Hacker News Discussion ↗

Imagining a world where CPUs are 20x slower prompts comparisons to past eras of computing, when limited hardware forced tighter code, fewer abstractions, and more rigorous testing. Many argue that today’s abundant compute has been “spent” on heavy frameworks, web stacks, and visual polish, trading responsiveness and efficiency for rapid feature development and cross‑platform convenience. Others note that a mere 20x slowdown would mostly delay current capabilities by a few years, but might have postponed AI advances, discouraged Electron‑style apps, and sustained a culture of performance‑conscious, lower‑level programming.

Overall framing

  • Many argue this isn’t very hypothetical: CPUs really were ~20x slower 10–20 years ago, so looking back is instructive.
  • Others push back that the question assumes hardware stays slow while software keeps evolving, which is different from “we’re just 8.6 years earlier on Moore’s law.”

Performance, optimization, and bloat

  • Consensus that tighter CPU budgets would force:
    • More attention to algorithmic efficiency, memory usage, and cache behavior.
    • Less tolerance for heavy abstraction layers and “just throw hardware at it” attitudes.
  • Several note that “doing less” is usually the biggest optimization; 20x slower hardware would reinforce this.
  • Wirth’s Law and Jevons-like effects are invoked: faster hardware has been largely “eaten” by heavier software stacks.

UI frameworks, desktop vs web

  • Many predict:
    • More native C/C++ desktop apps, fewer large browser engines and Electron-style apps.
    • UI frameworks more like VB6/Delphi/early Qt/WPF, emphasizing fast, small binaries and responsive controls.
  • Strong nostalgia for 90s/2000s RAD tools and native toolkits; people contrast them with sluggish, multi-layer web UIs.
  • Others note old systems were often sluggish on their contemporary hardware; perceived “speed” today is partly running old software on new machines.

Parallelism, GPUs, and architecture

  • Several expect much heavier emphasis on:
    • Multicore, SIMD, and GPGPU earlier and more pervasively.
    • Domain-specific accelerators and Cray-like vector/array processing.
  • Some discussion that slower clocks would also affect buses, memory, and displays, making the tradeoffs more complex.

Applications: games, web, AI, cryptography

  • Games: predictions range from “still Doom/Quake-level graphics” to “more strategic/intellectual designs and less flashy spectacle.”
  • Web: likely more static pages, fewer heavyweight client-side frameworks; less tracking/analytics overhead simply because it would be too slow.
  • AI: many doubt current large-scale deep learning and LLMs would exist; compute and training costs would be prohibitive.
  • Crypto: 20x slower/faster alone is minor for security margins; algorithms like 3DES/AES choices would change slowly.

Economics, culture, and skills

  • Slower hardware is seen as:
    • Increasing the value of deep systems knowledge, complexity analysis, and formal methods.
    • Reducing “bootcamp-style” shallow training and easy patch-after-release practices.
  • Some argue management would still prioritize shipping features over optimization; constraints help, but culture remains decisive.