Comment by skrebbel | Hacker News Reader

Comment by skrebbel | Hacker News Reader

Parent Full thread

> Basically the message was that serial performance is saturating, and the only way to get speed improvements in the future is going to be by exploiting parallelism.

People have been warning us about this for about 10 years now, but I still don't see those 64-core CPUs I was promised anywhere.

If we had the amount of parallelism we were told we were going to get, we could give every app its own core. OSes could even consider disabling context switches altogether for the majority of apps. Instead, we're left complaining about Electron apps like it matters.

That said, I'm not sure what stagnation you refer to. There's a reason languages like Rust, Elixir/Erlang and Go are getting popular. My PHP app could handle hundreds of concurrent connections on a single machine, my Elixir app handles hundreds of thousands. Yet, processors didn't get 1000x faster (and Elixir isn't even a particularly fast language). This is the opposite of stagnation, it's progress.

They have been here for a while, just for a very specific market.

Threadripper and EPYC exist now though. With 32 and 64 logical cores respectively.

Sure, there's been high end niche products for anything forever. You could buy a 64 core computer in 1990 (they'd call it a supercomputer, but same thing).

The people telling us we had to go change our code to use parallel processing fast predicted a significantly faster increase in amount-of-cores on commodity hardware. Instead, CPUs stopped getting faster and hardly gained more parallellism.

You could buy a 64 processor machine in 1990, but it wouldn’t have been a 64 core machine in the sense we’re talking about — a single socket system. This isn’t some trivial distinction either, as the whole memory architecture is very different indeed for the two scenarios.

Even in single-socket configurations, Threadripper and EPYC are still both NUMA architectures - the cores are split across two or four dies, each of which has its own memory controller and memory attached to it, with requests from a core to memory on another die going via an interconnect.

those 64-core CPUs I was promised

The people promising that were crackpots and no one really called them out on it, so that meme got repeated everywhere despite being wrong. Processor vendors can't release a new processor that runs existing apps slower because no one would buy it (not counting monopolistic tactics). And since many existing apps are single-threaded, that means new processors have to at least maintain the same single-threaded performance which means keeping brainiac cores which means you can only afford 6-8 of them. (And arguably there are 64 weak cores in your CPU; they're just in the IGP and you have to program them with OpenCL.)

Go/Rust/Elixir are not so much progress IMO as undoing the negative progress of writing large-scale software in scripting languages.

There are plenty of 64 cores servers. Yet, multi-core architectures seem to have hit a wall caused by slow memory access.

I'm still waiting for the massively parallel NUMA machine in a chip, but there are many manufacturing problems keeping those away.

And hit a wall for power/density.

https://en.wikipedia.org/wiki/Dark_silicon

If you can find an Nvidia GTX 1080, that has 2560 cores.

Without branching (or with limited branching, last I checked it masked and re-ran instead). A core implies both instruction and data operations, rather than SIMD behavior.

They're playing games with the term 'core'.

In CPU terms, a 1080 is 40 cores, each with a 64 way vector unit.

I'm surprised they don't sell it as a 40 core, 64-dimensional processor.

Where "core" ~= vector lane

Reply on news.ycombinator.com