[Developers] how to use CCTK_RESTRICT
tradke at aei.mpg.de
Fri Oct 7 10:46:35 CDT 2005
Erik Schnetter wrote:
> On Oct 7, 2005, at 08:20:52, Thomas Radke wrote:
>> I'm currently doing some investigation on Cactus performance
>> profiling and optimisation. One of the things I've tried was using
>> restrict pointers in MoL (whether this is a reasonable thing to do
>> I'll ask in a separate thread on this mailing list) in the way that I
>> define them as in
>> const CCTK_REAL* CCTK_RESTRICT RHSVar;
>> CCTK_REAL* CCTK_RESTRICT UpdateVar;
>> To my surprise I found that the CCTK_RESTRICT macro expands to an
>> empty string so that my changes had no effect at all. I made sure
>> that the C/C++ compiler (in my case it's Intel) does support the
>> qualifier, and the Cactus configure script does recognise it.
>> What I don't understand is the logic in lib/make/cctk_Config.h.in
>> which defines/undefines CCTK_RESTRICT depending on the value of
>> CCTK_C_RESTRICT (and CCTK_CXX_RESTRICT respectively for C++). I
>> believe it is a bug that the macro expands to nothing iff
>> CCTK_C_RESTRICT is undefined. Or am I missing something here ?
> MoL is written in C, and "restrict" is a keyword there, defined in ANSI
> C. You should be able to use "restrict" instead of "CCTK_RESTRICT".
> Cactus autodetects it properly. Only C++ code has problems, because
> Cactus does not #define "restrict" to anything in C+ +, since "restrict"
> is not a keyword in the C++ standard.
I just learned from Jonathan that the "restrict" keyword is there in the
C99 standard, not (necessarily?) in earlier versions.
Are you suggesting to generally use "restrict" when writing Cactus C/C++
code, and then rely on cctk_Config.h to do the right thing ? Then we
should rename "CCTK_RESTRICT" into some Cactus internal macro name such
as "CCTKi_RESTRICT", shouldn't we ?
Or should we rather use "CCTK_RESTRICT" in which case the logic in
cctk_Config.h (and in your patch) could be simplified ?
More information about the Developers