Naturally, as with all my posts, I'm not referring to x86 :) L1 is rarely ~1 cycle access, there are even a few architectures that can't write to L1 at all, and I've never come in contact with a compiler that can do anything useful with the const keyword in C. That said __restrict is fundamentally different than const, const suggests I can't change the memory pointed at, when that is often exactly what I intend to do.
It seems to be very hard to convince people who have never had to work on these platforms that it's really important :/ On 21 October 2011 06:49, Robert Jacques <sandf...@jhu.edu> wrote: > On Thu, 20 Oct 2011 07:37:22 -0400, Manu <turkey...@gmail.com> wrote: > >> Caching results manually is very tedious work, and makes a mess of your >> code.. If you've had to do that yourself you'd understand how annoying it >> can be. >> > > I do do it all the time and I've never found it that tedious. Especially > compared to all the loop invariant divisions, expressions, function calls, > etc you have to excise from the loop anyways... I mean, L1 cache has a > latency of ~ 1 cycle, division is ~50-150 cycles. > > > Placing restrict on sensible pointers is much cleaner and saves a lot of >> time, and also results in optimisation everywhere it is used, rather than >> just the 1-2 places that you happened to notice it was a problem... >> > > Except that you should only use __restrict where you notice a problem. In > case you didn't know, C++ compilers do (did?) all the __restrict > optimizations for const variables. And the systematic use of const on these > compilers is a well known source of Heisen-bugs. I haven't heard that this > 'feature' has been disabled, but its been a while since I checked. >