3 ms·
I agree that it will be a large power penalty, but the alternative may end up being the long tail of software suffering subtle concurrency correctness issues th
by reitzensteinm 6y ago
I agree that it will be a large power penalty, but the alternative may end up being the long tail of software suffering subtle concurrency correctness issues that just aren't there on x86. It may sacrifice some of their advantage but avoid being known as the CPU equivalent of a Ford Pinto.
There's still plenty of room to undercut Intel's historical 60% gross margins even if you're shipping largely interchangeable products.
The other way it might play out is a race to very high core counts as the main differentiator, providing single socket performance worth the hassle of not being able to run everything on it in a rock solid way. Postgres will work great. That redis fork that adds threads maybe not.
Or Intel may start to allow developers to relax memory correctness guarantees on a process by process granularity in their own progress to high core counts. It's hard to imagine their current methods scaling to 1k cores. But if you asked me ten years ago I'd have said they wouldn't have made it to 56 cores, either.
- zozbot234 6y ago> Or Intel may start to allow developers to relax memory correctness guarantees on a process by process granularity If Intel can allow developers/OS's to relax guarantees, why can't ARM allow OS's to strengthen them as necessary, while still keeping a relaxed memory model most of the time?
- reitzensteinm 6y agoSure, although you'd probably be better off with strong by default with opt in weakness. The amount of testing and verification in making sure something like Postgres runs well on a different memory order more is substantial. Adding the flag at the end is trivial. This way around, software is correct by default unless it explicitly asks to be unsafe.