[Developers] what datatype to use in inter-language APIs (was: Re: [Patches] more efficient synchronisation of groups)

Erik Schnetter schnetter at cct.lsu.edu
Mon Jul 3 12:43:25 CDT 2006


On Jul 3, 2006, at 11:49:53, Thomas Radke wrote:

> 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
>>>>>> the subject.]
>>>>>
>>>>> 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:
>>>
>>> integer idx
>>> 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

That is not quite the scheme we use currently; this scheme is used  
only in the interpolation API.  For example,  
CCTK_GroupStorageIncrease passes integer arrays, and so do  
CCTK_Grouplsh and friends, and CCTK_StaggerDirArray and friends.  The  
cctkGH entries are also integer arrays.

I would rather describe the current scheme as "flesh uses int,  
aliased functions use CCTK_INT", with interpolation being the exception.

> 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.

Not quite.  Consider the case where a user wants to synchronise two  
groups at the same time.  He/she would then write

integer groups1(2)
CCTK_INT groups2(2)

call CCTK_GroupIndex (groups1(1), "bla")
call CCTK_Groupindex (groups1(2), "bla")
groups2 = groups1
call CCTK_SyncGroupsI (cctkGH, 2, groups2)

The conversion from "integer" to "CCTK_INT" has to be explicit, which  
is an inconvenience.  Alternatively, one can write

CCTK_INT, parameter :: idummy = 0
integer, parameter :: ik = kind(idummy)
integer groups(2)

call CCTK_GroupIndex (groups(1), "bla")
call CCTK_Groupindex (groups(2), "bla")
call CCTK_SyncGroupsI (cctkGH, 2, int(groups,ik))

Here, the conversion is done with the array operation "int(..., ik)".

> 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.

If we assume that anyway...  then why make some arguments integers,  
others CCTK_INT?

> 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.

That would be nice.  We can do that also with arrays, especially with  
small arrays like this one containing grid function indices.

> 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
> Cactus.
> Is that common agreement ?

Given the current ambiguities with some functions using int, others  
using CCTK_INT, I don't know what is best.  I seem to be advocating  
using int instead of CCTK_INT, but I really only want to point out  
some of the problems.  I don't know what the best solution would be.

-erik

-- 
Erik Schnetter <schnetter at cct.lsu.edu>

My email is as private as my paper mail.  I therefore support encrypting
and signing email messages.  Get my PGP key from www.keyserver.net.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://www.cactuscode.org/pipermail/developers/attachments/20060703/c32f1389/attachment-0001.bin 


More information about the Developers mailing list