cik@l.cc.purdue.edu (Herman Rubin) (07/04/90)
In article <138349@sun.Eng.Sun.COM>, lm@snafu.Sun.COM (Larry McVoy) writes: > In article <1990Jul3.215128.23026@portia.Stanford.EDU> dhinds@portia.Stanford.EDU (David Hinds) writes: > > Geez, is this a cheap shot, or what? FORTRAN has its weaknesses, > >but inefficiency is not one of them. I know of no other language that > >can be as effectively optimized. > > Yeah, I used to like fortran pretty well. I have before me "Programmers Guide > to Fortran 90" which contains things, such as pointers, that make me wonder > if this is going to make fortran an uninteresting language. That a language can be optimized (and I do not think that Fortran has ever been effectively optimized) says nothing about the efficiency of the language. There are important constructs, such as pointers, which have been missing from Fortran from day 1. There are others, such as a list of results of an operation, which have been missing from the commonly used languages completely. I understand that Fortran 90 is eliminating or restricting some of the useful, but not much used, features of Fortran considered bad by language gurus. The use of an ASSIGNED goto, especially without list, can make life difficult for the automatic optimizer, but it can sure speed up a program. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet) {purdue,pur-ee}!l.cc!cik(UUCP)
dhinds@portia.Stanford.EDU (David Hinds) (07/05/90)
In article <2306@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: >> > Geez, is this a cheap shot, or what? FORTRAN has its weaknesses, >> >but inefficiency is not one of them. I know of no other language that >> >can be as effectively optimized. > >That a language can be optimized (and I do not think that Fortran has ever >been effectively optimized) says nothing about the efficiency of the language. >There are important constructs, such as pointers, which have been missing from >Fortran from day 1. What do you mean by "effectively optimized"? I would guess that for your statement to be valid, you mean that NO language has ever been effectively optimized. This may be true, but is beside the point. As a trivial example, our MIPS Fortran compiler uses the same global optimizer as all other MIPS compilers, so Fortran is certainly at least as well optimized as any other language on the machine. The optimizer does take some advantage of language specific features, though, so Fortran is probably somewhat better-optimized. We also got a tool with the compiler that (almost) automatically determines data dependencies, unrolls loops, and parallelizes our Fortran code. Gee, there doesn't seem to be (maybe can't be?) a tool like that for our C compiler. Only the Fortran compiler has a "-mp" flag... I think it is fair to say that mature mainframe Fortran compilers are "effectively optimizing". IBM's compilers are supposed to be quite good, and difficult to beat with hand-coded assembler. And Fortran is still the language of choice for vector architectures, I think. I agree that in many ways, Fortran stinks, but for some tasks, it is still the best tool available. With a preprocessor so I never need to type a line number or a CONTINUE statement, I can grudgingly bear it. -David Hinds dhinds@Popserver.stanford.edu
cik@l.cc.purdue.edu (Herman Rubin) (07/05/90)
In article <1990Jul4.173753.23361@portia.Stanford.EDU>, dhinds@portia.Stanford.EDU (David Hinds) writes: > In article <2306@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: > >> > Geez, is this a cheap shot, or what? FORTRAN has its weaknesses, > >> >but inefficiency is not one of them. I know of no other language that > >> >can be as effectively optimized. > > > >That a language can be optimized (and I do not think that Fortran has ever > >been effectively optimized) says nothing about the efficiency of the language. > >There are important constructs, such as pointers, which have been missing from > >Fortran from day 1. > > What do you mean by "effectively optimized"? I would guess that for your > statement to be valid, you mean that NO language has ever been effectively > optimized. This may be true, but is beside the point. As a trivial example, > our MIPS Fortran compiler uses the same global optimizer as all other MIPS > compilers, so Fortran is certainly at least as well optimized as any other > language on the machine. My statement stands. What I was really getting at is that I cannot even tell the compiler what I want to do in any sensible manner much of the time, and, in addition, the optimization is usually far worse than a human with reasonable understanding will do, if you let the human do things the compiler does not know about. Now some of the newer machines have removed those useful instructions. The optimizer does take some advantage of language > specific features, though, so Fortran is probably somewhat better-optimized. > We also got a tool with the compiler that (almost) automatically determines > data dependencies, unrolls loops, and parallelizes our Fortran code. Gee, > there doesn't seem to be (maybe can't be?) a tool like that for our C > compiler. Only the Fortran compiler has a "-mp" flag... I have not looked much at parallel processors, but I have at vector processors. There are many algorithms which do not parallelize worth a darn. Some of these can sometimes be vectorized, but a single instruction can make a big difference. But I do not know how to write those things in Fortran (or any other HLL) in such a way that any compiler I have seen can recognize what is wanted. Some of these situations are quite simple--the gurus just have not thought of them. > I think it is fair to say that mature mainframe Fortran compilers are > "effectively optimizing". IBM's compilers are supposed to be quite good, > and difficult to beat with hand-coded assembler. And Fortran is still the > language of choice for vector architectures, I think. I agree that in > many ways, Fortran stinks, but for some tasks, it is still the best tool > available. With a preprocessor so I never need to type a line number or > a CONTINUE statement, I can grudgingly bear it. A graduate student working for me who had never programmed for a vector computer was amazed at how little of the vectorizable code in a rather simple algorithm was not vectorized. Of course, that could have been predicted, as there were certain parts of the code which could only be vectorized if the machine were understood, and without these, some of the rest did not look right. BTW, much of that could not have been vectorized on the CRAY 1, but could with great difficulty on the X-MP. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet) {purdue,pur-ee}!l.cc!cik(UUCP)
wright@stardent.Stardent.COM (David Wright @stardent) (07/12/90)
In article <2306@l.cc.purdue.edu>, cik@l.cc.purdue.edu (Herman Rubin) writes: >I understand that Fortran 90 is eliminating or restricting some of the useful, >but not much used, features of Fortran considered bad by language gurus. >The use of an ASSIGNED goto, especially without list, can make life >difficult for the automatic optimizer, but it can sure speed up a program. They also make life hell for the poor bastard who gets stuck maintaining a program that some efficiency freak coded. Assigned gotos are an abomination, and anybody who uses one should be flogged around the public square at high noon. -- David Wright, not officially representing Stardent Computer Inc wright@stardent.com or uunet!stardent!wright Actually, I didn't want to *gently* chide Jake. I wanted to castrate him and run his balls up the flagpole to see if anyone saluted them. Besides Jake. -- Jack Douglas
jlg@lanl.gov (Jim Giles) (07/14/90)
From article <1990Jul12.011358.4130@Stardent.COM>, by wright@stardent.Stardent.COM (David Wright @stardent): > [...] Assigned gotos are an > abomination, and anybody who uses one should be flogged around the public > square at high noon. Assigned GOTOs are no worse than variable pointers in data structuring. The two concepts _are_ isomorphic after all. J. Giles
jamiller@hpcupt1.HP.COM (Jim Miller) (07/14/90)
>>I understand that Fortran 90 is eliminating or restricting some of the useful, >>but not much used, features of Fortran considered bad by language gurus. >>The use of an ASSIGNED goto, especially without list, can make life >>difficult for the automatic optimizer, but it can sure speed up a program. > >They also make life hell for the poor bastard who gets stuck maintaining >a program that some efficiency freak coded. Assigned gotos are an >abomination, and anybody who uses one should be flogged around the public >square at high noon. > > -- David Wright, not officially representing Stardent Computer Inc > wright@stardent.com or uunet!stardent!wright > >Actually, I didn't want to *gently* chide Jake. I wanted to castrate >him and run his balls up the flagpole to see if anyone saluted them. >Besides Jake. -- Jack Douglas >---------- Ah, it's nice to live in a world were it will not make any difference whether or not your program takes 1 day or 10 days of CRAY time just so the maintainer will not have to keep the documentation/comments up to date. However, some of us are forced to live in the world and our products will be used by people who, when faced with a program that takes 100 minutes to do a function that a competitors does in 10 minutes, will pick the 10 minute model -- despite the increased difficulty of the competitors to support their program. Ah, the indignities we force on others because we love to eat, sleep, and continue to work -- and make the customer happy. Seriously, "unsupportable" constructs HAVE been known to improve performance by a factor of 5 to 10. Often they CAN be maintained -- by proper use of comments & tools & documentation. Having said that. May I attend the flag raising for those who do unsupportable "optimizations" as a matter of course. Making the 80% of the code that does 20% of the work as difficult a support task as any other piece of code -- like the 2% that does 50% (I've seen some). And yes, I do realize that the first avenue of attack should be the algorithm. (and the second and the third). jim - without the Mimimum Acceptable Level of Performance, you don't have a product - miller My company doesn't know I have these opinions, let alone approve of them. jamiller@hpcupt1.cup.hp.com
peter@ficc.ferranti.com (Peter da Silva) (07/16/90)
In article <6000009@hpcupt1.HP.COM> jamiller@hpcupt1.HP.COM (Jim Miller) writes: > However, some of us are forced to live in the world and our products will > be used by people who, when faced with a program that takes 100 minutes to > do a function that a competitors does in 10 minutes, will pick the 10 minute > model Ah, if this was only the case in the PC world. Then Microsoft Windows wouldn't be in the process of overtaking the Macintosh in the marketplace. Really, I used to buy this argument, but after watching the absolute disasters that have actually sold, while really efficient systems (like the Amiga) languish in the shadows... well, I think Murphy writes the rules here. -- Peter da Silva. `-_-' +1 713 274 5180. <peter@ficc.ferranti.com>