Re: Unformatted, big-endian files and fseek
- From: nospam@xxxxxxxxxxxxx (Richard Maine)
- Date: Thu, 21 May 2009 09:29:21 -0700
Infinity77 <andrea.gavana@xxxxxxxxx> wrote:
inquire(1, recl=something)
return "something" as being 510.
That's not directly related, though it is at least vaguely so. For a
sequential file, that should return the maximum record length. The
length of individual records can vary (which is why the length
information needs to be stored for each record). Anyway...
I am current using the old Compaq Visual Fortran 6.6C, and I really
don't think it has F2003 support.
Probably not. But I am nearly certain that it has the same
functionality, if perhaps in some other form. Probably someone else here
knows, as it is still a compiler used by several. I'd look in the docs
for things like form='transparent', or perhaps 'binary'.
I am mainly trying to do all this
machinery to speed up the reading of the data. Do you think that using
F2003 I/O will improve the reading speed versus reading the whole
bunch of data?
I wouldn't count on it. Particularly not for amounts of data as small as
100 bytes or so that your example mentioned, though perhaps that was
just a tiny case. I/O is often optimized for sequential reading. Now if
you are talking really large offsets, that's a different matter. I've
dealt with wanting to read small portions at various positions in files
that were on the order of a gigabyte in size. In that case, it can make
a huge difference to position to the right spot several hundred
megabytes into the file instead of reading sequentially to it. But if
you are just skipping over hundreds or thousands of bytes, I predict it
would not be worth the bother.
Could you please recommend a compiler which has F2003 I/
O support? It would be nice if a free alternative was available, but
as I need it to play nice with Python and f2py I'll take what the
community suggest.
As I said, most of them have the functionality in one form or other. The
f2003 stream I/O feature was a case of standardizing a form for a
functionality that was already very widely supported in varying forms.
The latest versions of most compilers probably support the f2003 stream
I/O syntax (I think, for example, that the latest version of the Intel
compiler that is the successor to CVF does). But you aren't going to see
a speed difference in changing syntax. It is just a standardized syntax
for the same functionality.
I probably would not change compilers for that reason alone. However, if
I were using a compiler that used a nonstandard syntax for the
functionality, I would isolate and document the use of the nonstandard
forms. ("Isolate and document" is almost a mantra with me for
nonstandard things.)
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
.
- Follow-Ups:
- Re: Unformatted, big-endian files and fseek
- From: Infinity77
- Re: Unformatted, big-endian files and fseek
- References:
- Unformatted, big-endian files and fseek
- From: Infinity77
- Re: Unformatted, big-endian files and fseek
- From: Richard Maine
- Re: Unformatted, big-endian files and fseek
- From: Infinity77
- Unformatted, big-endian files and fseek
- Prev by Date: Re: Leading zero for printing real numbers
- Next by Date: Re: Unformatted, big-endian files and fseek
- Previous by thread: Re: Unformatted, big-endian files and fseek
- Next by thread: Re: Unformatted, big-endian files and fseek
- Index(es):
Relevant Pages
|
