Don’t underestimate __restrict

In high performance code, it’s usually important that the compiler is allowed to optimise as much as possible. Loading and storing values should be grouped together, because that reduces cache interaction. However if you have a function such as this:

void foo(int* a, int* b)
{
	int v = a[2];
	a[2] = 55 + v;
	
	v = b[4];
	b[4] = 66 + v;
}

The compiler will be forced to store the value into a, before attempting to read the value from b. However, that’s completely unnecessary. The compilers do this because they can’t guarantee that writing in a doesn’t modify b. You have to tell them if that’s so. You tell them with the restrict keyword:

void foo(int* __restrict a, int* __restrict b)
{
	//...
}

Now the compiler can optimise the calls dealing with a and b separately. This is capable of causing very nice speedups in many cases.

Since the use of __restrict isn’t widely accepted, certainly using it should be documented in case future programmers run into unexpected behaviour which would be super hard to debug.

One limitation of using __restrict is that accessing a member of a restricted pointer must be done in a separate code block such as this:

foo* restrict myObject   = &inObject;

{
	float* restrict objectPos = &myObject->pos; 
}

TLDR: You should try to use __restrict more often.

Leave a Reply

Your email address will not be published. Required fields are marked *