Weird Fortran i/o?

[Calvin H. Vu]

In <9105040132.AA10813 at fred> shc at fred.UUCP (Steve Couturie) writes:

| Well,:
| Re: Mail from Ian Graham --
| 
|   Re weird Fortran I/O times on IRIS 4D/25:
| > 
| > START-TIME         0.0100      0.0700
| > IO WRITE           8.9400      4.7600
| > IO READ           26.4600    353.0300 <<---!!!!!!
| > 
| 
| where the columns are user time and system time, respectively:
| 
| I tried the test code, and sure enough, it's weird.  BUT:
| a small modification makes it perform very well indeed:
| 
| Replace the REWIND with CLOSE.  Here are timings for 4 machines:
| 
| [21]dino:/tmp> ./quickc				# 4D/25TG, 64M mem, idle
|  START-TIME       0.00        0.03
|  IO WRITE         5.09        0.58
|  IO READ          7.62        0.88
| 
| [103]lhdsy1:shc/junk> ./quickc			# DEC 5400 Server, 64M mem, ?
|  START-TIME       0.01        0.04
|  IO WRITE        13.69       74.98
|  IO READ          7.53        2.24
| 
| 
	I ran the original unmodified program with the IRIX 4.0 release on a
4D/25 and got the following results:

 START-TIME     0.0000      0.0400
 IO WRITE     4.9300      0.2300
 IO READ     8.4100      0.5200

	So writing is slightly better than 3.3.1 and reading is
markedly better than 3.3.1 (but still not as fast as doing a CLOSE instead 
of a REWIND).

| I'd be interested in any comments from the SGI/Mtn.View folks....
| 
	It's a matter of second-guessing a user's intention whether he wants
    all readings or/and then all writings on a file or interspersed 
    reading/writings.  Depending on the guess is correct or not, some 
    implementation will be better than the others in a particular situation.
    This is a case where there is no perfect solution. It's just a matter
    of trying to get the best probability from the most general situations.

	The direct unformatted read bug has been fixed as you see in
    the timing result above.  [It was only a few days late in making
    the 3.3.2 maintenace release schedule :-(].

	As to why reading is still about 60% slower than writing I don't
    have the answer for you right now.  How about the next performance 
    improvement after the 4.0 release %-|.

	Doing a CLOSE when switching between READ and WRITE mode on the
    same file is a good strategy from the user so every time the file is
    opened only one type of I/O operation is done.  It should give the
    best performance available on the plaform when all readings are done
    at the same time and then all writings or vice versa.  Mixing 
    READ/WRITE/BACKSPACE/REWIND (as in transactional type of I/O 
    where people don't read the whole data file into a giant 10
    zillion byte array) would make a lot of systems hiccup in terms of
    performance.   For example, try the following benchmark:

	real tarr(2)
	real tend(2)
	start = etime(tarr)
	do 10 i=1,5000
	write(10) f, g
	rewind(10)
10	continue
	print *, "REWIND/WRITE loop: elapsed time = ",
	1 etime(tend)-start, tend(1)-tarr(1), tend(2)-tarr(2)


	start = etime(tarr)
	do 15 i=1,5000
	read(10) f, g
	rewind(10)
15	continue
	print *, "REWIND/READ loop: elapsed time = ",
	1 etime(tend)-start, tend(1)-tarr(1), tend(2)-tarr(2)

	open (2,file='scr8434.dat', access = 'direct',
     x  form='unformatted', recl=20)
	i1=1
	i2=2
	i3=3
	i4=4
	i5=5
	do 20 i=1,10
20	write(2, rec=i)i1, i2, i3, i4, i5
	start = etime(tarr)
	do 30 i=1,500
	do 40 j=1,10
	read(2, rec=j)i1, i2, i3, i4, i5
40	write(2, rec=j)i1, i2, i3, i4, i5
30	continue
	print *, "READ/WRITE loop: elapsed time = ",
	1 etime(tend)-start, tend(1)-tarr(1), tend(2)-tarr(2)
	end

	This is the timing result for the benchmark above on the 4D/25
    with 4.0 release:

 REWIND/WRITE loop: elapsed time =    4.350000       1.070000    
    3.280000    
 REWIND/READ loop: elapsed time =    2.600000      0.7099999       1.890000    
 READ/WRITE loop: elapsed time =    6.400000       1.720000       4.680000    


	Anyway, we did a minor overhaul on the I/O library for 4.0 release
    for many I/O operations and performance is much better now.  In 
    some cases, it could be as much as 50 times faster.  I created a 
    general I/O benchmark and got the 4.0 results for it which showed 
    super-turbo speed compared to 3.3 release.  But I assume it's proprietary
    so I can't really post it here :-(.   You just have to use your own 
    application/benchmark later and try it out I guess.

| -- 
| Steve Couturie                      Voice:     (213) 694-9332	
| Chevron Oil Field Research Co.      FAX:       (213) 694-7228
| P.O. Box  446                       Internet:  shc at chevron.com
| La Habra, CA  90633-0446            UUCP:      ...!uunet!lhdsy1!shc

- calvin
--
-----------------------------------------------------------------------------
Calvin H. Vu			   | "We are each of us angels with only one
Silicon Graphics Computer Systems  | wing.  And we can only fly embracing
calvin at sgi.com   (415) 962-3679	   | each other."