direct access with Intel fortran
in [Fortran]
|
From: John Paine on 8 Feb 2010 03:05 "Richard Maine" <nospam(a)see.signature> wrote in message news:1jdkdtz.g5qisl1wket36N%nospam(a)see.signature... > John Paine <johnpaine1(a)optusnet.com.au> wrote: > >> "Richard Maine" <nospam(a)see.signature> wrote in message >> news:1jdk4w1.162yhg4tspypsN%nospam(a)see.signature... > >> > Well form='binary' is not standard Fortran, so if that is the >> > objective, >> > this would not achieve it even if it did act like you wanted. >> > >> I knew I was vulnerable on that front and was hoping that nobody would >> notice. I know it's not standard, but I'm assuming that it'd be a brave >> vendor who left it out in the forseeable future. > > Lots of vendors already don't have it. Pretty much all of them have some > kind of stream-like functionality, but the details do vary already. If a > large majority of vendors already did it the same way, that way probably > would have been adopted as the standard instead of introducing stream. > But they don't, so it wasn't. > > Now if you are talking about the odds of Intel in specific dropping it, > I'd agree those odds would be low. But the odds of some other random > vendor happening to have it are much more questionable. > > (I see you are happy with the suggestion to use stream, so these points > are perhaps a bit academic). That sums up the situation pretty well. I guess a better way for me to have exressed it is as a more selfish one: pre-stream I wouldn't have used a compiler that didn't do what I wanted it to (or at least I would not have used it if it required too much rewriting of code). Post-stream, the same comments would probably still apply. So it's not so much about bravery of vendors (as from your comments, they've moved on and I haven't), but more about my slowness in changing vendors (I still use CVF for most of my code), moving with the times (I still code mostly F77) and narrowness of platform (solely Windows). But even with my slowness and change-resistance, I'm still managing to keep my clients pretty happy and there are much more interesting things to do than rewrite code that already works reasonably well (even if it is non-standard). Thanks again John > > -- > Richard Maine | Good judgment comes from experience; > email: last name at domain . net | experience comes from bad judgment. > domain: summertriangle | -- Mark Twain
From: Tim Prince on 8 Feb 2010 04:44 On 2/7/2010 10:50 PM, Richard Maine wrote: > John Paine<johnpaine1(a)optusnet.com.au> wrote: > >> The one point that troubles me is that the "pos=" keyword uses a number that >> "indicates a file position in file storage units in a stream file ". This >> seems to be bytes, but I thought that I saw a comment in the Intel >> documentation (which I can't locate at the moment), that the "storage unit" >> is system dependant. Also, I can't find any way to inquire what the unit >> might be. > In this case, the recommendation is that the storage unit be an octet > (which is standard-speak for an 8-bit byte). In practice, I don't think > you will ever find a compiler that doesn't at least have an option for > the storage unit to be that. For ifort, that option is -assume byterecl (replace space separator by : for Windows) (in case it hasn't already been mentioned somewhere in the thread)
From: Tim Prince on 8 Feb 2010 04:45 On 2/7/2010 10:50 PM, Richard Maine wrote: > John Paine<johnpaine1(a)optusnet.com.au> wrote: > >> The one point that troubles me is that the "pos=" keyword uses a number that >> "indicates a file position in file storage units in a stream file ". This >> seems to be bytes, but I thought that I saw a comment in the Intel >> documentation (which I can't locate at the moment), that the "storage unit" >> is system dependant. Also, I can't find any way to inquire what the unit >> might be. > In this case, the recommendation is that the storage unit be an octet > (which is standard-speak for an 8-bit byte). In practice, I don't think > you will ever find a compiler that doesn't at least have an option for > the storage unit to be that. For ifort, that option is -assume byterecl (replace space separator by : for Windows) (in case it hasn't already been mentioned somewhere in the thread)
From: John Paine on 8 Feb 2010 08:17 "Tim Prince" <tprince(a)computer.org> wrote in message news:7ta4qbF2dpU2(a)mid.individual.net... > On 2/7/2010 10:50 PM, Richard Maine wrote: >> John Paine<johnpaine1(a)optusnet.com.au> wrote: >> >>> The one point that troubles me is that the "pos=" keyword uses a number >>> that >>> "indicates a file position in file storage units in a stream file ". >>> This >>> seems to be bytes, but I thought that I saw a comment in the Intel >>> documentation (which I can't locate at the moment), that the "storage >>> unit" >>> is system dependant. Also, I can't find any way to inquire what the unit >>> might be. > >> In this case, the recommendation is that the storage unit be an octet >> (which is standard-speak for an 8-bit byte). In practice, I don't think >> you will ever find a compiler that doesn't at least have an option for >> the storage unit to be that. > For ifort, that option is > -assume byterecl > (replace space separator by : for Windows) > (in case it hasn't already been mentioned somewhere in the thread) It hadn't been mentioned, but I picked that up in the documentation for the the ISO_FORTRAN_ENV intrinsic module: "FILE_STORAGE_SIZE: Is the size of the file storage unit expressed in bits. To use this constant, compiler option assume byterecl must be enabled."
From: James Van Buskirk on 8 Feb 2010 12:19
"John Paine" <johnpaine1(a)optusnet.com.au> wrote in message news:4b6fc223$0$12922$afc38c87(a)news.optusnet.com.au... > Once again I amazed by your detailed knowledge and willingness to put even > trivial questions such as mine into the much broader context of language > standards and their evolution. The FILE_STORAGE_SIZE value in the Intel > intrinsic module (which I didn't even know existed, let alone what it > might contain) is indeed 8 and the documentation tells me that it is > measured in bits. So I do have an ability now to ensure that I am > reading/writing at the position I expect in the stream. Though from the > context you provide, it's going to be pretty unlikely that it'll be > anything I don't expect it to be. That was one reason why I created a structure that mapped to the whole header: there was no need to know the details of how to move around in the file if we were just going to replop the whole blob of data there at the beginning. Also it modularized the code so that the WRITE statements that created the dummy and real header wouldn't have to change even the the header changed. Assuming the header isn't itself huge, the extra cost of rewriting parts of the header that were known at file creation time should be negligible. -- write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, & 6.0134700243160014d-154/),(/'x'/)); end |