[Developers] what datatype to use in inter-language APIs (was: Re: [Patches] more efficient synchronisation of groups)
tradke at aei.mpg.de
Mon Jul 3 11:49:53 CDT 2006
Tom Goodale wrote:
> On Mon, 3 Jul 2006, Erik Schnetter wrote:
>>On Jul 3, 2006, at 09:54:14, Tom Goodale wrote:
>>>On Mon, 3 Jul 2006, Tom Goodale wrote:
>>>>On Mon, 3 Jul 2006, Thomas Radke wrote:
>>>>>After some discussion, Jonathan and I came to the same conclusion. So I
>>>>>will change the API back to using C integers then.
>>>>>I wonder why we designed other flesh interfaces to take CCTK_INT arrays,
>>>>>for instance CCTK_InterpGridArrays() or CCTK_ReduceGridArrays() ?
>>>>>[If this starts a whole new discussion thread we should probably change
>>>>CCTK_INT is supposed to guarantee the same size for the type in both
>>>>languages; just using 'int' and 'INTEGER' do not.
>>>This has caused problems on machines in the past - e.g. the T3E.
>>Consider the Fortran code:
>>call CCTK_VarIndex (idx, "thorn::var")
>>which calls the C wrapper:
>>void CCTK_FNAME (CCTK_VarIndex) (int * idx, CCTK_ONE_FORTRANSTRING);
>>This works only if int and integer have the same size. Many compilers have
>>switches, especially Fortran compilers, to select the size of an integer.
>>Many compilers use the same back end for both Fortran and C code, and
>>presumably Fortran and C will become more "similar" (i.e., interoperable) in
>>the future, not less. The T3E is dead.
>>If you are really concerned about integer sizes, then you have to make all
>>arguments CCTK_INT, not just the arrays.
>>Howver, look e.g. at the Fortran WaveToy examples. None of them handle
>>CCTK_INT correctly in their calls to Boundary_SelectVarForBC; they all assume
>>that CCTK_INT is the same as integer. This is even worse than assuming that
>>int and integer are the same, since CCTK_INT can be set to be integer*8.
>>Using different integer types is a place where Fortran and C differ much. In
>>C, using a different integer types is not much of a deal, since routine
>>arguments are automatically converted. They are not automatically converted
>>in Fortran, and this leads to complicated code.
> I'm not saying we have always been consistent in the past. We have not,
> and this has caused problems. What I am saying is that we should do
> better in future.
I tend to follow Tom's suggestion to stick with the current scheme of using
* native datatypes for passing scalar arguments
* CCTK datatypes for passing array arguments
in inter-language APIs. This shouldn't introduce any inconvenience for
Fortran programmers when setting up their function array arguments;
scalars can still be passed as native Fortran datatypes, for passing
literal constants in F77 code that is the only thing possible anyway.
This will work as long as the (so far) implicite assumption is true that
a native Fortran datatype is equivalent to the corresponding native C
datatype. If we had a machine where this is not true then I can't image
how Cactus would ever run there.
It also leaves us with the possibility to make it an explicite
assumption later, ie. determine in the configure script the C equivalent
to a native Fortran integer, and use that C datatype in all the Fortran
wrappers, without changing all the APIs again.
But let's keep this latter issue separate from the first so that I can
proceed with my revised patch for optimising group synchronisation in
Is that common agreement ?
More information about the Developers