This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch, fortran] Unformatted array IO performance improvement


> Anyway, I found the reason: The size of the array elements is stored
> in "index_type dtype" in the descritor, and the size is retrieved by
> shifting 6 bits to the right. Thus on 32-bit platforms the maximum
> size is 2**24, or 16 MB. Is there any practical need for arrays of >16
> MB characters, or can we say this is an implementation limit and
> nobody will care?
>
> > Can you pass the length of a character array the same way that
> > the recent patches to the reshape arrays introduced?
>
> You mean a transfer_array_char library entry point with an extra
> argument specifying the length of the characters, and leaving the size
> in the descriptor for sizeof(char)=1? Yes, I guess that would be one
> way. 

This is the correct solution. When writing the array descriptor stuff I got 
this wrong. The descriptor field should be the character kind, not the 
length.

> Another could be to simply make the dtype field 64 bits on all 
> platforms.
>
> >  I think this
> > would also be more consistent with the size of an array not being
> > consistent with its string length.
>
> Hmm, I think support for non-8-bit chars will require some major
> surgery of the formatted transfer routines. I'm not sure I want to go
> there now.

Maybe not, but it would be nice to get to a state where it could be 
implemented without changing the format of array descriptors, preferably 
without changing the ABI at all.

Paul


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]