3 ms·

If you want a safe and convenient language, why are you using C? Plenty of reasons, besides raw speed! If I just want speed and don’t care about safety at all,

If you want a safe and convenient language, why are you using C? Plenty of reasons, besides raw speed! If I just want speed and don’t care about safety at all, I’d be using assembly, right? C has (somewhat) strong typing which catches some errors at compile time. It has higher-level constructs than assembly, like function calls and loops. It’s exceptionally portable (although you have to be wary of undefined behavior and platform-specific weirdness). Speed is definitely an important part of the story but it’s by no means the only part. If you don't think C should be as fast as possible, which language should? How would that language differ from C? Something like FORTRAN maybe? No pointers, as I understand it, hence no aliasing problems. Unrestricted pointers aren’t necessarily great for speed, but they’re great for flexibility, which makes C a great systems language. FORTRAN might do matrix operations faster, but C is better for wrangling a fiddly file system data structure. Again, it’s not all about speed. it’s quite legal to pass aliasing pointers, and the compiler is free to introduce a check for aliasing Right, what I’m getting at is, the compiler is also free not to add a check, and most compilers do not in fact add a check, because they care more about speed. In fact most C compilers seem to go further; aliased pointers of different types can lead to undefined behavior, so the compiler assumes that this behavior cannot happen, and therefore that the pointers cannot be aliased. That seems to me a logical leap too far.

MaxBarraclough 8y ago
> If I just want speed and don’t care about safety at all, I’d be using assembly, right? Not really. C is a reasonable choice of language for high-performance code. There may be instances where your hand-written assembly can outperform compiled C, but it's far from guaranteed, and of course even if you did have such a guarantee, it might not be worth the productivity impact. Even performance-critical codebases like the Unreal Engine don't use much assembly, as far as I know. > Speed is definitely an important part of the story but it’s by no means the only part. Agree. > Something like FORTRAN maybe? No pointers, as I understand it, hence no aliasing problems. Indeed, but my understanding is that the performance wins there aren't exactly night-and-day. C is pretty close to as fast as it gets. > Right, what I’m getting at is, the compiler is also free not to add a check, and most compilers do not in fact add a check, because they care more about speed. I was unclear - I meant the compiler is permitted to add a check and then use a special optimised path in the case that the pointers do not alias. It’s quite legal to pass aliasing pointers. When compiling a function which has two pointer-to-int parameters, the compiler is not permitted to assume that they do not alias, unless you use the 'restrict' keyword (which is rarely seen as it's so risky). > aliased pointers of different types can lead to undefined behavior Correct (with the special exceptions of void* and char*). Because you shouldn't be doing that.

MaxBarraclough 8y ago

> If I just want speed and don’t care about safety at all, I’d be using assembly, right? Not really. C is a reasonable choice of language for high-performance code. There may be instances where your hand-written assembly can outperform compiled C, but it's far from guaranteed, and of course even if you did have such a guarantee, it might not be worth the productivity impact. Even performance-critical codebases like the Unreal Engine don't use much assembly, as far as I know. > Speed is definitely an important part of the story but it’s by no means the only part. Agree. > Something like FORTRAN maybe? No pointers, as I understand it, hence no aliasing problems. Indeed, but my understanding is that the performance wins there aren't exactly night-and-day. C is pretty close to as fast as it gets. > Right, what I’m getting at is, the compiler is also free not to add a check, and most compilers do not in fact add a check, because they care more about speed. I was unclear - I meant the compiler is permitted to add a check and then use a special optimised path in the case that the pointers do not alias. It’s quite legal to pass aliasing pointers. When compiling a function which has two pointer-to-int parameters, the compiler is not permitted to assume that they do not alias, unless you use the 'restrict' keyword (which is rarely seen as it's so risky). > aliased pointers of different types can lead to undefined behavior Correct (with the special exceptions of void* and char*). Because you shouldn't be doing that.