7-Zip for Windows can now use more than 64 CPU threads for compression

Original Article ↗ Hacker News Discussion ↗

7-Zip’s new ability to use more than 64 CPU threads on Windows highlights long‑standing quirks in the OS’s processor group and affinity model, which historically limited a single process to 64 hardware threads unless it explicitly handled multi‑group scheduling. Commenters debate how meaningful this change is in practice, noting that compression is often I/O-bound and not trivially parallel, while also comparing Windows’ approach to NUMA and core scaling with Linux and other systems. The conversation broadens into whether 7-Zip risks losing relevance to newer algorithms like Zstandard and to Windows 11’s built‑in archive support, with some pointing to forks such as 7-Zip-Zstd and NanaZip, and others arguing that 7-Zip’s ubiquity, format support, and simple integration into the Windows shell keep it firmly entrenched.

Windows >64‑thread limitation and processor groups

  • Windows exposes “processor groups” of up to 64 hardware threads, with per‑group affinity masks baked into old APIs and parts of the driver ABI.
  • Earlier 7‑Zip counted cores via affinity masks, capping it at 64 threads; newer APIs (e.g. GetActiveProcessorCount with ALL_PROCESSOR_GROUPS) and explicit group handling are needed to see and use more.
  • On systems with multiple groups, 7‑Zip now spreads worker threads across groups itself; Windows doesn’t fully abstract this on pre‑11 releases.
  • There is disagreement over how much Windows 11’s updated scheduler automatically spreads a single process across groups versus still requiring app changes for optimal use.
  • Some note compression isn’t trivially parallel: too‑small chunks hurt ratio, shared dictionaries need coordination, and IO often bottlenecks before CPU on huge archives.

Historical design and scaling debates

  • Early NT used 64‑bit affinity masks when >64 CPUs were exotic; many see that as reasonable for 1990s hardware.
  • Others argue high‑core SMP/NUMA existed on non‑x86 systems in the late 90s, and NT’s limits may have discouraged high‑core x86 servers.
  • Timeline points: NUMA scheduling in NT 5.0, processor groups in 6.1, and x86 systems surpassing 64 cores only becoming common in the 2010s.
  • Linux also had hardcoded CPU limits but tends to break ABIs more readily to scale up.

7‑Zip’s role vs Windows built‑in tools

  • Many still see 7‑Zip as the de‑facto Windows archiver: free, fast, supports many formats, simple context‑menu integration, good encryption.
  • Others say Windows 11’s libarchive‑based support for ZIP/7z/RAR/TAR makes 7‑Zip less necessary for casual users.
  • Reports say the built‑in tool is significantly slower and flakier on very large, many‑file archives.
  • Opinions on the 7‑Zip GUI are split: some call it dated but efficient, others prefer alternatives like PeaZip or NanaZip; many just use the right‑click menu.

zstd, other codecs, and compatibility

  • Some worry 7‑Zip will lose relevance without native zstd; community forks (7‑Zip‑zstd, NanaZip) add it but upstream development is described as very closed to contributions.
  • Others claim most end‑users don’t care about zstd; ubiquity and compatibility of classic ZIP (DEFLATE) dominate.
  • The ZIP spec now defines zstd (method 93) and other methods, but real‑world support is patchy; many systems still use old zip/unzip without these.
  • There’s a long back‑and‑forth on “good enough” formats (DEFLATE, JPEG, H.264) vs pushing newer tech (zstd, LZMA, H.265/AV1), and on the cost to users of requiring updated tools.

Cross‑platform tools and UX

  • On Unix‑like systems, tar plus gzip/xz/zstd and bsdtar/libarchive provide a similar “open almost anything” role to 7‑Zip.
  • macOS users miss 7‑Zip’s Windows shell integration; suggested alternatives include Keka, PeaZip, and CLI 7‑Zip via Homebrew.