(j3.2006) a question on c_f_pointer call

Bill Long longb
Fri Aug 27 11:57:49 EDT 2010



Aleksandar Donev wrote:
> On 08/27/10 03:43, Malcolm Cohen wrote:
>> also suspect that Aleks could be correct in surmising that the same 
>> vendors who get the C_F_POINTER case wrong *might* also get certain 
>> cases involving TARGET wrong too.
> Or, if those compilers really do get all the TARGET cases right 
> (including paths via external libraries compiled separately), then I 
> need to be convinced in Bill's claim that the performance cost of doing 
> a hash lookup (or whatever is used to establish if a block of memory was 

Certainly a poor performer.

> allocated by the allocator earlier) is larger than doing some sort of 
> calculation at every pointer assignment to check if the association is 

I would not want to do calculations at every pointer assignment either. 
Also bad for performance. Arguably worse.

> with all the elements of a valid target and thus deallocation is valid, 
> and then pass that information around in all descriptors forever and ever.

For many implementations (excluding NAG, evidently) the needed 
information is included in the descriptor.  Until we introduced 
C_F_POINTER and C_LOC, that worked fine.   With these new facilities, 
the descriptor information is largely lost in transition, so either we 
change the rules to exempt these cases (Malcolm violently protests), 
have some vendors (but not NAG) make fundamental changes (very expensive 
and disruptive), or put the onus on C_LOC  and C_F_POINTER to store 
somewhere and then restore the needed information (also a lot of work, 
but not nearly as disruptive).  If the first option is not available, 
the last one is the most likely.  It would result in major performance 
degradation of C_LOC and C_F_POINTER, but that is balanced by the 
probability that they are almost never used.

Cheers,
Bill

-- 
Bill Long                                           longb at cray.com
Fortran Technical Support    &                 voice: 651-605-9024
Bioinformatics Software Development            fax:   651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101





More information about the J3 mailing list