Prev: passing a type of different KIND to a C function from Fortran binding
Next: lost of efficiency of operator overloading
From: glen herrmannsfeldt on 26 May 2010 20:09
bio_amateur <hoangtrongminhtuan(a)gmail.com> wrote:
(big snip in KIND conversion, C, size_t, call by value, etc.)

> Thank you for all the help. So, it's clear to me that using
> VALUE means creating a copy on the background.

Somewhere a copy must be made, yes.

But C doesn't pass arrays by value, but instead passes a pointer
to the array (by value), so that a copy of the array is not made.
(C will pass structures containing arrays by value, though.)

> I just want to make clear that I'm using 64-bit system.

The purpose of size_t is to hold the size of a memory region,
such as allocated by malloc(). For many programs, a 64 bit
size_t might not be necessary, and especially not (at least with
current systems) a large array of them.

> Now, the situation is that I have an array which is quite large, and
> passing by reference to the C function. Now, we'll see that creating a
> duplicate is not a good choice. So, if we know a way, such as using
> pointer to typecast and pass it to the C function. We can get higher
> performance.

Are you really allocating a large number of regions that are
each greater than 4GB? For most systems, especially 64 bit systems,
an array of 100MB would not be considered large, and 100MB of
eight byte size_t would be over 12 million. If each was used
to allocate 4GB, that would be 50PB. (Only 25PB if you stop
at 2GB, as int is signed.)

So, use an int (C_INT) array, pass it by reference (as usual
for C and Fortran), and then convert each element to size_t
just before calling malloc(). (With a prototype, C will do
the conversion for you.) If the array is really large,
then short (or C_INT16_t) might be enough.

Assuming these are sizes of some type larger than char, keep
them as the number of such array elements until just before
calling malloc(), which will give you a little more room before
they aren't big enough.

Otherwise, explain in a little more detail to get a more
specific answer.

-- glen
From: glen herrmannsfeldt on 26 May 2010 20:13
Richard Maine <nospam(a)see.signature> wrote:
(snip)

> One can also take a c_ptr, possibly one obtained from C_LOC, and create
> a Fortran pointer from it (see the c_f_pointer function). You are
> "supposed" to only to that if the Fortran pointer is the "right" type
> for the data being pointed to. But compilers are unlikely to be able to
> check that (I did only say "unlikely", which gives me an out if you find
> one that manages to do such a check in simple cases). This probably
> gives you a way to "lie" to the compiler and do much of the same kind of
> trickery that you can often get by with in C.

Compilers are not likely to detect it, but some might detect
it at run time. There used to be systems with tagged memory,
where each memory location knew what type was stored in it.
That is rare now.

Also, the JVM verifier, normally used with Java, but could run
code from other compilers. A Fortran compiler targetting JVM
would be interesting.

> As with most such
> trickery, it is again up to you to figure out if it will achieve the
> intended result. If you expect it to achieve "magic", you are likely to
> be dissappointed. Changing the physical representation without either
> copying or altering the original would count as magic.

-- glen
 | 
Pages: 1
Prev: passing a type of different KIND to a C function from Fortran binding
Next: lost of efficiency of operator overloading