Thread (21 messages) 21 messages, 9 authors, 2009-01-21

Re: gcc inlining heuristics was Re: [PATCH -v7][RFC]: mutex: implement adaptive spinning

From: Nick Piggin <hidden>
Date: 2009-01-20 00:51:32
Also in: linux-fsdevel, lkml

On Tue, Jan 20, 2009 at 08:01:52AM +1100, Linus Torvalds wrote:

On Mon, 19 Jan 2009, Nick Piggin wrote:
quoted
I want to know what is the problem with the restrict keyword?
I'm sure I've read Linus ranting about how bad it is in the
past...
No, I don't think I've ranted about 'restrict'. I think it's a reasonable 
solution for performance-critical code, and unlike the whole type-aliasing 
model, it actually works for the _sane_ cases (ie doing some operation 
over two arrays of the same type, and letting the compiler know that it 
can access the arrays without fearing that writing to one would affect 
reading from the other).

The problem with 'restrict' is that almost nobody uses it, and it does 
obviously require programmer input rather than the compiler doing it 
automatically. But it should work well as a way to get Fortran-like 
performance from HPC workloads written in C - which is where most of the 
people are who really want the alias analysis.
OK, that makes sense. I just had a vague feeling that you disliked
it.

 
quoted
it seems like a nice opt-in thing that can be used where the aliases are 
verified and the code is particularly performance critical...
Yes. I think we could use it in the kernel, although I'm not sure how many 
cases we would ever find where we really care. 
Yeah, we don't tend to do a lot of intensive data processing, so it is
normally the cache misses that hurt most as you noted earlier.

Some places it might be appropriate, though. It might be nice if it can
bring code size down too...
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help