Xref: utzoo comp.lang.c:10845 comp.lang.fortran:790 Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!pioneer!eugene From: eugene@pioneer.arpa (Eugene N. Miya) Newsgroups: comp.lang.c,comp.lang.fortran Subject: Re: C vs. FORTRAN Keywords: C FORTRAN vectorizing supercomputers religion Message-ID: <10704@ames.arc.nasa.gov> Date: 22 Jun 88 18:18:39 GMT References: <3136@phoenix.Princeton.EDU> Sender: usenet@ames.arc.nasa.gov Reply-To: eugene@pioneer.UUCP (Eugene N. Miya) Organization: NASA Ames Research Center, Moffett Field, Calif. Lines: 41 In article <3136@phoenix.Princeton.EDU> mjschmel@phoenix.Princeton.EDU (Michael J. Schmelzer) writes: >Given that C produces assembly code very similar to the source >code it came from, why should it be any slower than the object >code generated by a FORTRAN compiler? > >Furthermore, wouldn't optimizers eliminate any difference between >their final products? My two yen: Your fallacy is sort of based on the separation of parts in compilation and an assumption from everything is performed properly: a common misconception. For instance, compilers appear as very monolith things to most people (like me), only recently have companies started writing compilers in high-level languages, started thinking about common code generators for different languages, etc. Sure, the binary machine instructions all have to work in the machine instruction environment, but many machines had different optimizers for their different language compilers. This is changing as common intermediate codes are developing. The point is things are changing for the better. Consider that supercomputer sometimes make terrible byte pushers [over generalized]. In another case, we also tend to take a lot of features like optimization for granted. Most of these systems are poorly tested. This is not completely the fault of manufacturers. We ran un-vectorized libraries month before we found the mistake, this was not a production machine, a site configuration error. In another case, I reserved a big machine for stand alone use on micro-tasking research. I was expecting to see 4 CPU crunching a problem. Only 1 was working. The tasking package was distributed set up to only run on 1 CPU. Only a stand alone test would have detected this problem. TIme to recompile. Another gross generalization from --eugene miya, NASA Ames Research Center, eugene@aurora.arc.nasa.gov resident cynic at the Rock of Ages Home for Retired Hackers: "Mailers?! HA!", "If my mail does not reach you, please accept my apology." {uunet,hplabs,ncar,decwrl,allegra,tektronix}!ames!aurora!eugene "Send mail, avoid follow-ups. If enough, I'll summarize."