Apple's M4 has reportedly adopted the ARMv9 architecture

Original Article ↗ Hacker News Discussion ↗

Upgrade timing & buying strategies

  • Many users struggle with when to buy Macs given Apple’s regular chip cadence; waiting for “the next one” can lead to endless deferral.
  • Common strategies:
    • Buy on launch, then keep devices 2–6 years.
    • Intentionally buy previous-gen (often refurbished) after a new release for cost savings.
    • Only replace every 4–5 generations, often with used/refurb units.
  • Several note that M‑series chips are now “good enough” that chasing each generation yields minimal real-world benefit.
  • Others caution against first‑release hardware due to early bugs and prefer waiting a few months or a cycle.

Real‑world M‑series experiences

  • Users upgrading from older Intel Macs (2011–2019) report dramatic improvements:
    • Huge battery life gains, cool operation, near‑silent or never‑audible fans.
    • Big speedups for compiles, Docker, ML workloads, and 4K video editing.
  • Some keep very old Macs running with RAM/SSD upgrades and unofficial macOS patchers, but acknowledge no modern codec acceleration and worse video workloads.
  • One downside: M‑series laptops no longer double as “lap warmers.”

ARMv9, SME, and ISA details

  • Some claim the M4 “adopts ARMv9”; others argue it’s still ARMv8 with new extensions (e.g., SME), and binaries remain arm64e.
  • Consensus in the thread: ARMv9 is largely an incremental superset over ARMv8.5, not a radical change; more like adding AVX‑512 to x86 than a new architecture.
  • Debate on why vendors (especially Apple) haven’t broadly adopted SVE2; suggestions include implementation complexity, limited demonstrated benefits, and licensing/politics.
  • Discussion of Apple’s architectural ARM license and speculation about different licensing terms vs ARMv9, but details remain unclear.
  • Question raised whether MTE is finally enabled; participants say Apple chips support it in hardware but it is not exposed/used yet, and this remains unresolved.

Performance gains and bitcode

  • One view: M4 performance gains are overhyped and heavily tied to new matrix instructions that many apps won’t use.
  • Others counter that per‑clock gains vs M3 are real (0–20% in Geekbench, excluding SME subtests), and cherry‑picked benchmarks can mislead.
  • Bitcode is discussed: some thought it could have enabled auto‑recompilation for new instructions, but others say in practice it never delivered that, and auto‑vectorization for new ISAs is far from automatic.

Binary size, multi‑arch support, and app bloat

  • Concern that supporting more ISA variants will “double” binary size; replies note:
    • Adding a third architecture increases size ~50% if you already ship two.
    • In modern apps, code is typically a small fraction of size; assets (images, UI bundles, media) dominate.
  • macOS “fat binaries” with multiple architectures have existed for years; some recall four‑arch bundles (PowerPC, 32‑bit x86, 64‑bit x86, ARM64).
  • Discussion of Swift runtime distribution history; earlier iOS apps bundled their own Swift libraries, but current Apple platforms use shared runtimes.

Microsoft Teams on M4 and software inefficiency

  • Multiple comments note that even on powerful M‑series (including M4 iPad), Microsoft Teams can feel extremely sluggish, especially when typing or mentioning users.
  • Suggested causes include:
    • Heavy telemetry (possibly per‑keystroke and mouse‑movement logging) stressing CPU and RAM, particularly when network‑blocked.
    • Poor async design and excessive background workers.
    • Web‑tech/Electron‑style architectures leading to resource‑hungry clients.
  • Experiences vary: some say Teams is usable, others call it the worst app they must use; alternatives like Pidgin + Teams plugin are reported to be vastly lighter.
  • This is framed as an example of Wirth’s law and how modern software can negate hardware advances such as those in M‑series chips.