[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