Hacker News Reader

Comment by unwind | Hacker News Reader

This is old (2006), and seems to base its argument around the problems with unrestricted pointers in C, that cause aliasing.

As of C99, of course, C has the "restrict" keyword which allows pointers to explicitly be declared to not alias, thus enabling all these optimizations in C, too.

View on HN

And then there are SIMD compiler intrinsics. Not technically part of the C standard, but if you want them, C/C++ is where you find'em. Failing that there's inline assembly.

Ding. It's amazing what you can do with a decent set of vector operations.

Honestly, if you want balls-out performance, you probably need specialized hardware. In days of yore that meant you bought a vector box for your computer, or a Cray. These days you can just load up a PC with a bunch of high-end GPUs. A cow-orker of mine down the hall has a machine with six of them installed -- he's so giddy, it's kind of irritating :-)

if you use the Accelerate Framework on OSX or iOS, you have a very easy-to-use interface to vector ops (pass in pointers to your array..)

The problem with the C99 restrict is that its correct use is not (and cannot) be enforced by the compiler. For example, the following is legal C (in the sense that no compiler that I know of will issue as much as a warning):

void f(char * restrict p, char * restrict q); char * h() { static char s[10]; return s; } void g() { f(h(), h()); }

(Correctness of a program using restrict is, in general, not decidable.)

The tradeoff here is that while restrict can be used to allow for further aliasing, it is very easy to write code with undefined behavior as a result. Dennis Ritchie argued as much when he (successfully) kept "noalias", the precursor of "restrict", out of the C89 standard: http://www.lysator.liu.se/c/dmr-on-noalias.html (while "restrict" is not quite as dangerous as "noalias", it still has to be used with care).

I don't know the first thing about FORTRAN. How does it enforce this?

This is independent of what FORTRAN does. The problem with the "restrict" keyword in C99 is that introducing it can make otherwise correct code incorrect and the compiler can't tell you.

As to program analysis, programming languages without pointer arithmetic have it a lot easier than languages with. The pair (array, index) holds more information than the address of array[index]. For example, it is trival to perform array bound checks if you have the former information, but very hard if you deal with arbitrary pointers. Pointer arithmetic loses information.

In C restrict says in this function assume pointers don't alias. Which may or may not be true. This gives the library author a hard choice to make: limit usefulness or performance.

Fortran for the longest time(introduced in 90) didn't have pointers so there was no aliasing possible. With pointers in Fortran you have to specify what they may alias so the problem is much easier.(note: I have read about it but never actually worked in Fortran so I may be wrong.)

If "undefined behavior" were an argument for keeping features out of the language, the language we would have ended up with would not be C.

In addition to that, if you're using the Intel compiler, then you can say

   #pragma ivdep

Which tells the compiler that the loop you're writing doesn't have any vector dependencies. Or -fno-fnalias to say that none of the arguments you're passing to a function are aliased.

Seems like pretty reasonable ways around the problem. Not to mention things like OpenMP.

iirc the GCC equivalent of ICC's '-fno-fnalias' is '-fargument-noalias'. A pragma would be nice though.

Pragmas suck. What I want is to explicitly assert the condition:

  assert(a+n < b || b+m < a);

(saying that a[0..n] and b[0..m] don't alias) and have the compiler generate code that first tests the condition and generates optimized code given the assumption.

Thank you. I see some variant of this argument somewhere on the web every few months, and it makes me want to bang my head on the table.

Yeah, but you have to manually do that. Maybe I'm a purist, but I hate manual features that the compiler should just 'figure out.' At best it's an unneeded annoyance, at worst you can actively slow your program down or even cause it to be incorrect. Aliasing can be tricky even to experienced programmers, and it's nicer to just have a compiler figure it out for you. It will probably do a better job anyway.

While that would be nice, it's unfortunately not the reality. The computer falls into failed optimization traps all the time. The only difference is that with a human, you can detect it with a profiler and correct the problem by reordering a few things. With automatic optimization, you can't.

I really don't mind seeing people say "it's easier to do this and make it run fast in another language" - that's a completely fair argument. It just really annoys me when I see "C can't do this", when it can (and has been able to do so for a long time). It makes the author appear completely ignorant.

Exactly. The whole article seems to based on the writers ignorance about "restrict" keyword.

However the article had been valid if it were published before C99.

At first I didn't include the date in the title, because I don't think it matters, the author's position seems even stronger now with many popular alternative languages, fast VMs and effective JIT compilers. Anyway, C99 was, of course, already 6-7 years old in 2006.

And restricted pointers were probably available through compiler-specific language extensions way before that. You can still use them if you have legacy code that won't compile with c99.

Reply on news.ycombinator.com