[ET Trac] [Einstein Toolkit] #1975: Cactus: mark routines used by DECLARE_CCTK_ARGUMENTS as pure

Einstein Toolkit trac-noreply at einsteintoolkit.org
Fri Nov 4 08:54:22 CDT 2016


#1975: Cactus: mark routines used by DECLARE_CCTK_ARGUMENTS as pure
--------------------------+-------------------------------------------------
  Reporter:  rhaas        |       Owner:                     
      Type:  enhancement  |      Status:  new                
  Priority:  minor        |   Milestone:                     
 Component:  Cactus       |     Version:  development version
Resolution:               |    Keywords:                     
--------------------------+-------------------------------------------------

Comment (by anonymous):

 Technically, CCTK_VarIndex and CCTKi_VarDataPtr are not pure, since they
 depend on global state in addition to their arguments. I cannot think of
 an optimization that GCC or Clang would perform where this difference
 would matter, but we should be careful nonetheless.

 For example, the following (theoretical) optimizations would cause
 problems:
 - GCC calls CCTK_VarIndex during initialization (i.e. when the program
 starts up) instead of during run time; at that time, the parameter file
 has not been read, thorns have not bee activated, and variable indices are
 not yet known
 - GCC memoizes the variable pointer, which breaks when AMR is used and the
 variable pointer differs over time
 - GCC aggressively inlines (e.g. for a small test case), so that a thorn's
 routine is inlined into Carpet's schedule loop, making the different
 variable pointers visible without memoization

 I don't see any of these optimizations happening at the moment.
 Nevertheless, we should be aware that we're breaking GCC's assumptions
 here.

 In the mean time I'm all for it; reducing this overhead is important.

 A point of reference -- I tried declaring several Carpet routines "pure"
 or "const" in the past, and this led to random segfaults. I had to undo
 these changes. However, I suspect that at that time, the problem was code
 generation errors in the compiler. I hope that compilers have improved in
 the mean time.

-- 
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1975#comment:1>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit


More information about the Trac mailing list