Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!sdd.hp.com!decwrl!sgi!shinobu!odin!dinkum!calvin From: calvin@dinkum.wpd.sgi.com (Calvin H. Vu) Newsgroups: comp.sys.sgi Subject: Re: Weird Fortran i/o? Message-ID: <1991May6.233325.1490@odin.corp.sgi.com> Date: 6 May 91 23:33:25 GMT References: <9105040132.AA10813@fred> Sender: news@odin.corp.sgi.com (Net News) Organization: Silicon Graphics, Inc. Mountain View, CA Lines: 135 In <9105040132.AA10813@fred> shc@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@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@sgi.com (415) 962-3679 | each other."