Hacker News Reader

Comment by abainbridge | Hacker News Reader

This article is correct that your computer is not a fast PDP-11 but wrong that this has anything to do with C. Eg, "another core part of the C abstract machine's memory model: flat memory. This hasn't been true for more than two decades."

This has nothing to do with C. The hardware insists on this abstraction. And its a good job too, otherwise your programs would stop working when moved to a machine with different cache.

View on HN

The article argues that the hardware’s insistence on this abstraction is in large part _because_ of C’s dominance.

If only that were true. Lots of languages that have nothing to do with C also did it. It's just much easier to program with a unified memory model, that's all there is to it.

If by unified memory model you mean "flat address space" then no, it's not. The moment you need two (or more) dynamically-sized arrays, you need to implement realloc with memmov in the unfortunate case. In a world where each array could have it's own segment, this problem doesn't arise because they simply cannot intersect and realloc boils down into increasing/decreasing a segment's extent.

On the good[1] old times of x86 segments, you still couldn't assign a segment to each array as segments were a limited resource. Something still has to do the mapping of the segments to physical linearly addressable memory.

[1] spoiler alert: they were not good.

Wouldn't that just move the "magic" down to the kernel or the MMU which has to do the realloc and memmov hidden from the programmer instead of the programmer being able to chose when and how to do it?

Yes, but here's the thing: the virtual memory system already does this kind of "magic", maintaining the mapping of virtual addresses onto the physical ones, and it doesn't need to actually move data between physical pages at all since the mapping is discontinuous.

Many of those languages indirectly have lots to do with C – even if you ignore the obvious problems like "C is the only ABI supported by most OSes, C FFI is the only cross-language interface supported by most languages and thus most libraries", there's more subtle influenced: Copying e.g. the (very expensive to implement in hardware) cache semantics of C usually "costs" languages nothing, because the hardware is already there, due to C. Not copying them happens, if both language and hardware get developed at the same time, but it's much rarer.

You see similar problems with things like vectorization – Rust was in a good position to define semantics more amenable to ARM SVE / Risc-V VE, but all existing SIMD libraries are written for C and x86 semantics, so that's what Rust is currently stuck with, as are most other languages.

What “C semantics” are baked into Rust’s SIMD libraries?

Look at the github/reddit/etc discussions around getting variable-length vector extensions like SVE/RVE properly supported; all the libraries are designed for x86 semantics, which are the way they are to make them easily implementable in C.

I’m still confused. What are “x86 semantics”? What does this have to do with C? I understand if SIMD libraries were designed for e.g. SSE or AVX first but I’m not sure how that relates here.

But we have/had architectures that expose parallelism at the instruction set. Eg itanium and graphcore. And the PS2 made cache management the programmer's problem. I don't think any of these experiments proved successful in the long run.

Hence the observation that every architecture eventually converges to NUMAcc if physically possible.

People have written C code that dealt with more complex memory schemes.

The language matters less than the fact that there's a lot of existing code around. That code needs to keep working.

Yeah. A lot of the things that make C not low level in the terms of this article happened on IBM mainframes decades before x86:

* tiered memory hierarchy pretending to be flat RAM

* CPUs that are much bigger than the ISA suggests, and which have out-of-order and speculative execution so code can make good use of their resources

* optimizing compilers that further decouple the program as written from its execution

IBM was working on this stuff in the 1970s, well before the rise of C. It’s fair to criticize the model and seek out alternatives, but it isn’t fair to blame C.

Flat memory is a bad thing for performance. Especially cache-coherent flat memory. It is convenient for programmers.

Yeah, agreed. My comment should really have been, "I'm glad modern ISAs are high level because low level ones would be a massive burden". And, "It isn't C's fault that low level ISAs are a massive burden".

Reply on news.ycombinator.com