Xref: utzoo comp.lang.c:10934 comp.lang.fortran:813 Path: utzoo!utgpu!water!watmath!rwwetmore From: rwwetmore@watmath.waterloo.edu (Ross Wetmore) Newsgroups: comp.lang.c,comp.lang.fortran Subject: Re: C vs. FORTRAN Keywords: C FORTRAN vectorizing supercomputers religion Message-ID: <19633@watmath.waterloo.edu> Date: 27 Jun 88 18:14:49 GMT References: <3136@phoenix.Princeton.EDU> Reply-To: rwwetmore@watmath.waterloo.edu (Ross Wetmore) Organization: U. of Waterloo, Ontario Lines: 55 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? > >What is missing from the equation here? I am currently writing >programs in C and FORTRAN and thus have some interest in the matter. >Mike Schmelzer mjschmel@phoenix!princeton.edu Part of the problem is that the presence or absence of certain constructs in the high level language predisposes the programmer towards a particular algorithm or coding style. Thus an algorithm written in simple Fortran might be quite radically different than one written in simple C. In C exponentiation is not an operator, but rather a function. I have seen C programs where a for-loop has been used to avoid doing a pow() function call or because simple integer exponentiation doesn't really exist. A Fortran programmer doesn't really think and just uses '**' which usually just gets translated into an appropriate function call by the compiler. The point is that the C programmer may produce a radically different program because of the different thought process required. The reverse happens when a C concept like pointers is missing from the language. What is needed is a way to preprocess code or add compiler extensions so that the expression of simple concepts can be done with simple high-level code and the implementation is left to the compiler. Even better is if the extensions can be added dynamically by the programmer for his particular application, rather than rewriting the code to use a compiler which has the maximum overlap with his favorite set. For example a scientific application package might be a trivial program in a language where a data types 'vector' and 'matrix' existed with standard operators '+-*/' doing the appropriate thing. Moreover if a new super-hardware device comes along to replace the functions that presumably get called to do the actual work, then the user need do very little more than recompile with a new compiler switch or function library. This is far more preferable and less time consuming than global changes to explicit programmer implement- ation of the same functionality. Rather than converting Fortran to C, or Cobol, or PL/1, it might be more worthwhile to look at some of the more flexible languages such as C++ or ADA or their future incarnations. Hopefully, the relearning cycle and upgrade path for these will be somewhat less steep after the initial conversion, as the basic compiler is less liable to change, but rather different packages of 'includes' will come along to provide extensions and new features. Ross W. Wetmore | rwwetmore@water.NetNorth University of Waterloo | rwwetmore@math.Uwaterloo.ca Waterloo, Ontario N2L 3G1 | {uunet, ubc-vision, utcsri} (519) 885-1211 ext 3491 | !watmath!rwwetmore