home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.lang.fortran
- Path: sparky!uunet!paladin.american.edu!howland.reston.ans.net!usc!sol.ctr.columbia.edu!eff!news.oc.com!convex!patrick
- From: Patrick F. McGehearty <patrick@convex.COM>
- Subject: Re: Fast I/O
- Originator: patrick@wagner.convex.com
- Sender: usenet@news.eng.convex.com (news access account)
- Message-ID: <1993Jan22.193019.12936@news.eng.convex.com>
- Date: Fri, 22 Jan 1993 19:30:19 GMT
- Reply-To: patrick@convex.COM (Patrick F. McGehearty)
- References: <1jhqkhINNno3@bigboote.WPI.EDU> <1993Jan21.081105.4047@molene.ifremer.fr>
- Nntp-Posting-Host: wagner.convex.com
- Organization: Engineering, CONVEX Computer Corp., Richardson, Tx., USA
- X-Disclaimer: This message was written by a user at CONVEX Computer
- Corp. The opinions expressed are those of the user and
- not necessarily those of CONVEX.
- Lines: 23
-
- In article <1993Jan21.081105.4047@molene.ifremer.fr> molagnon@ditigo.ifremer.fr writes:
- (revised for brevity):
- Why don't compilers optimize I/O lists such as
-
- write (lu) (a (j), j=1,n)
- to be as fast as
- write (lu) a
-
-
- Convex Fortran does, and in the recent past, also added the optimization for:
- write (lu) (a (j,i), j=1,n)
-
- In my opinion, the answer to the question is that there is no technical
- reason for compilers to not make this optimization. Rather it is a
- question of resources and structural pressures. There are always more
- potential optimizations and features to add to a language like Fortran
- than there are resources to add them (Fortran 90 makes this statement
- self-evident :-). If a compiler group has been entirely driven by the old
- simple benchmarks such as Whetstones, Dhrystones, and Linpack 100x100,
- they will not even realize that there is a worthwhile optimization to be
- made in this case. If they use real production applications, then the
- optimization may get on their to-do list, depending on their target market
- segment.
-