|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
DanRRight
Joined: 10 Mar 2008 Posts: 2826 Location: South Pole, Antarctica
|
Posted: Fri Aug 17, 2012 10:26 am Post subject: FLUSH (unit) |
|
|
is Fortran 2003 feature. Do we have something like that? If not it's probably worth to add to FTN95
Description:
Flushes Fortran unit(s) currently open for output. Without the optional argument, all units are flushed, otherwise just the unit specified.
Option: gnu
Class: non-elemental subroutine
Syntax: CALL FLUSH(UNIT)
Arguments: UNIT (Optional) The type shall be INTEGER.
Note:
Beginning with the Fortran 2003 standard, there is a FLUSH statement that should be prefered over the FLUSH intrinsic. |
|
Back to top |
|
|
davidb
Joined: 17 Jul 2009 Posts: 560 Location: UK
|
Posted: Fri Nov 16, 2012 8:50 pm Post subject: |
|
|
You could re-open the connection, something like:
Code: |
SUBROUTINE FLUSH_UNIT(UNIT)
INTEGER, INTENT(IN) :: UNIT
OPEN(UNIT, POSITION='ASIS')
END SUBROUTINE FLUSH_UNIT
|
Open can be used on an already open/connected unit to change the attributes of the connection. _________________ Programmer in: Fortran 77/95/2003/2008, C, C++ (& OpenMP), java, Python, Perl |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2826 Location: South Pole, Antarctica
|
Posted: Mon Nov 19, 2012 5:33 pm Post subject: |
|
|
Interesting suggestion, thanks David.
Never heard before about "ASIS" and that you can 'mess' like that with already open file. LOL |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2556 Location: Sydney
|
Posted: Tue Nov 20, 2012 4:05 am Post subject: |
|
|
David,
I could not find much in the F95 standard to indicate what happens if you re-open a file that is already opened. Does this ensure that the file buffers are cleared by the OS ? Not a lot in the standard on how the OS manages the file buffers !!
It's a bit hard to understand why ASIS is the default for position=, when in almost all cases OPEN is used to conect a file for the first time, with no predefined position.
John |
|
Back to top |
|
|
davidb
Joined: 17 Jul 2009 Posts: 560 Location: UK
|
Posted: Tue Nov 20, 2012 9:11 am Post subject: |
|
|
John,
POSITION="ASIS" should only be used when OPEN is used to re-open an pre-existing connection. There are several Changeable connection mode specifiers that can be altered by re-opening a file. In"The Fortran 2003 Handbook" they are listed as:
BLANK
DELIM
PAD
DECIMAL (F23 only)
ROUND (F23 only)
SIGN (F23 only)
In addition, you can change ERR= and IOSTAT= in the re-open statement.
I don't know for sure that this will do a "flush", you would have to experiment with it. However, it seems likely that it will. In "Fortran 95/2003 Explained, Metcalf, Reid, Cohen" it says the effect is as if the file is closed and opened again. I am guessing this is what FTN95 does (being careful with scratch files!). The implementation of close should call some routine to get the OS to flush the output buffers.
I agree its a bit strange ASIS is also the default when there isn't a pre-existing connection (the most common usage for OPEN as you say). In such cases, the effect of ASIS is undefined when the file already exists, so you shouldn't use it. Only use it when re-opening a connection. _________________ Programmer in: Fortran 77/95/2003/2008, C, C++ (& OpenMP), java, Python, Perl |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2556 Location: Sydney
|
Posted: Thu Nov 22, 2012 12:11 am Post subject: |
|
|
David,
I've written a disk I/O tester for testing :
small to large direct addressable binary files
on HDD and SSD
using XP and Win7
It goes through the stages of
opening (a new file)
writing
reading
writing randomly
reading randomly
closing and
deleting
It is interesting to see the elapsed time for each stage, especially reading and closing. Closing has a significant effect on measured elapsed time performance for what I expect is flushing the buffers, which I should test to identify the flushing effect of CLOSE vs reOPEN. (This is especially the case where the file size is less than the amount of physical memory, which was 2 to 4gb but is now typically 8 to 12 gb)
File size is tested in comparison to the amount physical memory installed, showing a significant difference between XP and Win7.
Retesting is becoming a problem, as I've lost most access to XP, which is not a bad thing when considering file buffers.
Also a few work pressures at the moment, so not the time available to do the retest, for more emphasis on the flush time. Will get back with some results when I can.
This use of FLUSH could be a good thing to consider, especially when testing a run time bug, where the file buffers are lost. Installing some temporary FLUSH commands might help, if you can anticipate where the bug is. Alternatively, it would be easier to have a buffer flush when an access violation or similar error occurs.
John |
|
Back to top |
|
|
davidb
Joined: 17 Jul 2009 Posts: 560 Location: UK
|
Posted: Fri Nov 23, 2012 6:17 pm Post subject: |
|
|
I will be interested to see what you discover when you have the time. _________________ Programmer in: Fortran 77/95/2003/2008, C, C++ (& OpenMP), java, Python, Perl |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|