Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: