Hacker News Reader

Comment by bullen | Hacker News Reader

What about memory contention when many cores try to write/read the same memory?

There is no point to add more cores if they can't cooperate.

How come I'm the only one pointning this out?

I think 4 cores will max out the memory contention, so keep on piling these 128 core heaters on. But they will not outlive a simple Raspberry 4!?

View on HN

It's likely that it's going to need a post on its own since it's an extremely complicated topic. Someone else wrote an awesome post about this for the Neoverse 2 chips [1] and they found that with LSE atomics, the N2 performs as well or better than Icelake. Given gravitron3 has a much wider fabric, I would assume this lead only improves.

[1] https://travisdowns.github.io/blog/2020/07/06/concurrency-co...

Ah, yes I remember this post, but it reads pretty cryptic to me. I would like to know what the slowdowns actually become in practice, does it add latency to the execution of other threads and how will the machine as a whole behave?

I know M4 had much better multicore shared memory perf. than M3, but now both of those are old and I don't have users to test anything now.

Reading the same memory usually ok.

Writing us not, but respecting the single writer principle is usually rule zero of parallel programming optimisation.

If you mean reading/writing to the same memory bus in general, then yes, the bus need to be sized according to the need of the expected loads (i.e. the machine need to be balanced).

The whole chip in general will be used in aggregate by independent vms/containers etc that do NOT read and write to the same memory. Some kernel datastructures within a given vm are still shared, ditto for within a single process, but good design minimizes that (per cpu/thread data structures, sharded locks, etc etc).

I don't think they were referring to contention across VM boundaries.

Reply on news.ycombinator.com