| > > Optimization, hardware. > Quite don’t understand why these concerns are “concerns” here. One of the most frustrating things about C is that it is generally taught together with assembly, so that there is a general conflation between C and assembly, as if C is both "just" some sort of portable assembler and the unique language with that property. The main consequence of this is that the C abstract machine [1] tends to be assumed to be the model of how processors work, and this ends up creating a lot of friction where the C abstract machines just doesn't match hardware newer than about 40 years old. It can be a little hard to understand just how bad the friction is if you haven't personally run across it, but here's a few examples: * Registers. C doesn't have a concept of registers [2], and there's not much of an easy way to really distinguish between "things that look like a load/store because the abstract machine assumes everything has a memory location" and "no, this is meant to actually issue a hardware machine load/store or this is meant to actually permanently live in a register." There's also minor stuff like the fact that the language makes it easier to express "A[i]" (load A + i * sizeof(A)) over "&A[i]" (A + i sizeof(A)) that makes it somewhat annoying if you want to express assembly concepts better. SIMD vectors. This is pretty common (at least across a desktop, server, or mobile CPU or GPU). But C has no way of expressing these types or how to use them, outside of compiler extensions (and there's like three incompatible versions of it). * There's a lack of concept of optimization, and concomitant issues like optimization barriers. Some things have slowly moved in (e.g., there's now an attribute to indicate a function call is speculatable), but in general, it's still difficult to tell the compiler to stop doing some optimization that might break your code. * No hardware speculation barrier concept, and similar other barriers for more exotic concepts like operations depending on the path condition of the function call (cryptographic code, which wants to be constant-time, or SIMT code tends to care about that a lot more). [1] Or at least what people assume the semantics of the abstract machine are. Let's be frank, the C userbase isn't very good at actually knowing what the C standard does and doesn't guarantee. [2] Yes, I know about the register keyword. No, it doesn't give C a meaningful concept of registers. |