home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / fortran / 5131 < prev    next >
Encoding:
Text File  |  1993-01-23  |  2.0 KB  |  49 lines
  1. Newsgroups: comp.lang.fortran
  2. Path: sparky!uunet!cs.utexas.edu!hellgate.utah.edu!lanl!cochiti.lanl.gov!jlg
  3. From: jlg@cochiti.lanl.gov (J. Giles)
  4. Subject: Re: Fast I/O
  5. Message-ID: <1993Jan22.181029.12646@newshost.lanl.gov>
  6. Sender: news@newshost.lanl.gov
  7. Organization: Los Alamos National Laboratory
  8. References: <1jhqkhINNno3@bigboote.WPI.EDU> <1993Jan21.081105.4047@molene.ifremer.fr>
  9. Date: Fri, 22 Jan 1993 18:10:29 GMT
  10. Lines: 37
  11.  
  12. In article <1993Jan21.081105.4047@molene.ifremer.fr>, molagnon@ditigo.ifremer.fr (Michel Olagnon, Ifremer DITI GO, 98.22.41.44) writes:
  13. |> [...]
  14. |> Many Fortran compilers are not efficient on I/O with implied DO loops.
  15. |> Replacing 
  16. |>       write (lu) (a (j), j=LO,HI)        ![generalize your case a bit]
  17. |> with
  18. |>       call fstwrt (lu, a(LO), HI-LO+1)    ![similar generalization]
  19. |>          .
  20. |>          .
  21. |>       subroutine fstwrt (lu, a, n)
  22. |>       double precision a (n)
  23. |>       write (lu) a
  24. |>       return
  25. |> usually gives dramatic improvement.
  26. |> 
  27. |> I have a follow-up question : why don't compilers execute this optimization ?
  28.  
  29. I asked Cray for something similar to this more than 5 years ago.
  30. In fact, they actually had an interface to the I/O library defined
  31. which not only passed the array and the length, but the stride as
  32. well.  This would have permitted buffered I/O for even strided
  33. data to run as fast as the example you gave.  (It doesn't help
  34. unbuffered I/O unless the stride is exactly one - in which case
  35. you get the same thing as you just posted.)  For some reason,
  36. even though Cray had the interface defined and the hooks in the
  37. compiler to implement it, they never did.  I estimated that it
  38. would have sped some I/O bound code by several times.
  39.  
  40. The reason for the speedup is that most implementations compile
  41. the implied loop into a tight loop around the I/O library call.
  42. The above made a separate trip through the I/O routines for each
  43. element of the array.  The whole-array write only takes a single
  44. trip through the library for the whole array.  The call/return 
  45. overhead often dominates for I/O on single elements.
  46.  
  47. -- 
  48. J. Giles
  49.