C vs. Fortran (half OT questions)
in [Fortran]
|
Prev: gcc4.4: f951: warning: command line option "-MM" is valid for C/C++/Java/ObjC/ObjC++ but not for Fortran
Next: Bad dependency relation for "gfortran"
From: Nick Maclaren on 10 Aug 2010 14:35 In article <i3s51c$nlo$1(a)speranza.aioe.org>, glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: > >Then again, different people have different ideas about >what they mean by IEEE 754. Yes, indeed. You know me well enough to know that I mean the standard, unless I state otherwise, but that's rare .... >> Nobody supports IEC 60559:2008 yet, as far as I know, and it is far >> from certain that it will get industry acceptance. It may simply >> get kicked into the long grass by the community, in much the same >> way that full C99 support has been. > >IBM has some support for the decimal float modes. Since they >did much of the work to get it into the standard, that isn't >too surprising. I don't know in detail how much of the standard >they support, though. Yes, quite. Intel will at least go there, but whether they will stay there is less certain. No doubt we shall hear shortly, accompanied by a flourish of strumpets, er, marketing executives. >Yes, but if you aren't careful you can write some very un-optimizable >code in Fortran. Some that are easy to write using for loops >in C, but are instead written using Fortran array intrinsic >functions requiring temporary arrays and much more processing >to get the desired result. Agreed, especially because many compilers are poor in that area. >With the assumption that you know what you want the compiled >code to look like, it is much easier to write C code to >generate that result than Fortran code. Yes and no. While it's true, it's deceptive. You need to know a LOT about C to avoid getting caught out by one of its innumerable gotchas. Fortran is clearer - play that sort of game, and you are outside the language and into the realm of compiler-specific code. Regards, Nick Maclaren.
From: Ron Shepard on 10 Aug 2010 17:32 In article <Rd2dndSu6ZUm4PzRnZ2dnUVZ7v4AAAAA(a)giganews.com>, Vincenzo Mercuri <comp(a)lang.c> wrote: > I've been always told of the C language as the best choice > to accomplish any kind of task in numerical algorithms implementation. Maybe newer versions of C are better, but the older versions of C were particularly bad when it came to numerical algorithms. For example, in traditional K&R C, parentheses could not be used to force operations to occur in a particular order, something that is very important when writing numerical code. Also, float arguments were promoted to double in all function calls, another troublesome feature when trying to write careful numerical code. And, of course, all arrays in C must be zero-based, which seldom matches the numerical problem at hand. Multidimensional arrays are also a problem in C, especially the ones with dimensions determined at runtime rather than with constants at compile time. The floating point declarations sometimes are a pain in C. For example, something declared as float on one machine might have the same precision as something declared as double or as long double on some other machine. And finally, perhaps the biggest problem with numerical code in C, is that the value of some simple expressions such as "i/j" in which either one or both of the integer values are negative were not defined in C (they could round either up or down); this means that to write truly portable C code you need to test for negative values and evaluate the expressions using positive values only. All these things are much better in fortran. Fortran has always respected parentheses in expressions, and fortran has never silently promoted arguments in subroutine calls. Fortran does allow mixed-mode and mixed-precision expressions, which are sort of like promotion, but the programmer has control over this in fortran by the way the expressions are written. Arrays in fortran can have any base at all, whatever best fits the problem at hand. Multidimensional arrays in fortran are no problem, they are as easy to declare, use, allocate, or deallocate as 1D arrays. Newer versions of fortran (since 1990) have a nice way of parameterizing floating point precision that avoids many of the portability problems in ancient fortrans (f77 and earlier); C has not yet caught up in this respect. And, "i/j" has always had a well-defined value in fortran for any combination of negative or positive integers (well, j cannot be zero, but that is a different issue). Also, fortran has a nice array syntax which allows complicated expressions to be expressed in a simple way, very much like the mathematical expression you would write on paper; being able to write clear, simple, code is important in numerical work. I would say that it is difficult to even think of a numerical problem that can be done better in C than in fortran. Of course, you can write bad or inefficient fortran code, but you can fix it within fortran, you don't have to switch languages to rewrite the bad code. On the other hand, if you want to write low-level code to communicate with some external device, then this is the sort of thing that is usually easier in C than in fortran -- but that is not numerical code, which is the topic in this thread. Also, C has always had associated with it a well-defined preprocessor, something that fortran has *always* needed but has really (practically speaking) never had; most modern fortran compilers can use the C preprocessor, but there are some problems with this approach that the programmer must avoid. > 1 -- is there any reason not to learn Fortran (a new language for me) > and focus on C (and C numerical libraries) potentialities? I don't really know how to answer this. I doubt that anyone who reads comp.lang.fortran is going to tell you not to learn fortran. > 2 -- is Fortran considered the best choice in this field only because > of its construct and syntax that makes easier to handle > mathematical entities? No, that is one of the reasons, but not the only reason. > > 3 -- what about the Standard IEEE 754 (IEC 60559:1989) conformance? > is that intrinsecal to the language or the implementation? > which language can offer a full support to the IEEE Standard, > C or Fortran? I don't know the full answer to this. There is IEEE support in standard fortran (since 2003), but I don't know how full or complete it is. > 4 -- what about performance? would you bet on C or Fortran? :-) The main problem with C performance is that the syntax has wild pointers. You can't avoid those -- even if you use array notation rather than pointers, that is defined to be equivalent, so you are stuck back with wild pointers which inhibit various compiler optimizations (such as storing a value in a register and using it multiple times). I think most of the other language features (in C and fortran) end up being a wash as far as efficiency. But those wild pointers are the elephant in the room. The C language is about 40 years old, and if that problem could be fixed, I would think it would have been by now. $.02 -Ron Shepard
From: Giorgio Pastore on 10 Aug 2010 18:18 Vincenzo Mercuri wrote: .... > I've been always told of the C language as the best choice > to accomplish any kind of task in numerical algorithms implementation. Amazing. I was told the same, but with C replaced by Fortran :-) > I'd like to do some serious programming in numerical analysis and > I'd like to read some opinion about whether C has too many limitations > or it is far a better choice than Fortran is. You are not mentioning what kind of external constraints you may have. For example, I would guess from your message that you do not know Fortran. But do you know C ? Are you planning to do some serious numerical programming just for fun or do you have a (tight) tie schedule ? Is the choice of the language completely to you or you have to convince someone else ? > that may seem trivial and not topical to this group (I've already > posted the same questions in comp.lang.c). Here they are: > > 1 -- is there any reason not to learn Fortran (a new language for me) > and focus on C (and C numerical libraries) potentialities? Difficult question to answer without additional information. By the way, I would be curious to know if by C you mean pure C or C++. I know a lot of people thinking that they are the same language :-( > 2 -- is Fortran considered the best choice in this field only because > of its construct and syntax that makes easier to handle > mathematical entities? Well, it depends what one is focusing on. Certainly the expressivity of a language is not a minor point in the choice, since most of the costs of sw are related to its maintenance and evolution. In this respect, I would not consider the choice between Fortran and C but instead between Fortran and C++. .... > 4 -- what about performance? would you bet on C or Fortran? :-) In average, judging on the basis of the available studies, there is no strong reason in favor of C or Fortran or C++. You may always find/write program difficult to optimize in whatever language you chose (actually slighty easier with C++). But, without knowing exactly what you plan to do, and in particular which kind of programming paradigm you like to use, it is difficult to say more. In my professional experience (academic research in condensed matter computational physics) I have used more than 10 different programming languages (without taking into account versions/dialects). I am Fortran/C bilingual but for many years I have used only Fortran for serious numerical work and C for more system oriented work. In the last 10 years I have become more and more interested in OO paradigm, so, even if I am not proficient in C++ as I am in Fortran/C, now, for a new project, my first question is about the alternative C++/Fortran not C/Fortran. Giorgio Giorgio
From: gmail-unlp on 10 Aug 2010 19:22 On Aug 10, 7:18 pm, Giorgio Pastore <past...(a)units.it> wrote: > Vincenzo Mercuri wrote: > > ... > > > I've been always told of the C language as the best choice > > to accomplish any kind of task in numerical algorithms implementation. > > Amazing. I was told the same, but with C replaced by Fortran :-) > > > I'd like to do some serious programming in numerical analysis and > > I'd like to read some opinion about whether C has too many limitations > > or it is far a better choice than Fortran is. > > You are not mentioning what kind of external constraints you may have. > For example, I would guess from your message that you do not know > Fortran. But do you know C ? Are you planning to do some serious > numerical programming just for fun or do you have a (tight) tie schedule > ? Is the choice of the language completely to you or you have to > convince someone else ? > > > that may seem trivial and not topical to this group (I've already > > posted the same questions in comp.lang.c). Here they are: > > > 1 -- is there any reason not to learn Fortran (a new language for me) > > and focus on C (and C numerical libraries) potentialities? > > Difficult question to answer without additional information. By the way, > I would be curious to know if by C you mean pure C or C++. I know a > lot of people thinking that they are the same language :-( > > > 2 -- is Fortran considered the best choice in this field only because > > of its construct and syntax that makes easier to handle > > mathematical entities? > > Well, it depends what one is focusing on. Certainly the expressivity of > a language is not a minor point in the choice, since most of the costs > of sw are related to its maintenance and evolution. In this respect, I > would not consider the choice between Fortran and C but instead between > Fortran and C++. > > ... > > > 4 -- what about performance? would you bet on C or Fortran? :-) > > In average, judging on the basis of the available studies, there is no > strong reason in favor of C or Fortran or C++. You may always find/write > program difficult to optimize in whatever language you chose (actually > slighty easier with C++). But, without knowing exactly what you plan to > do, and in particular which kind of programming paradigm you like to > use, it is difficult to say more. > > In my professional experience (academic research in condensed matter > computational physics) I have used more than 10 different programming > languages (without taking into account versions/dialects). I am > Fortran/C bilingual but for many years I have used only Fortran for > serious numerical work and C for more system oriented work. In the last > 10 years I have become more and more interested in OO paradigm, so, even > if I am not proficient in C++ as I am in Fortran/C, now, for a new > project, my first question is about the alternative C++/Fortran not > C/Fortran. Why OO in Fortran is not an alternative? Fernando.
From: Tim Prince on 10 Aug 2010 19:52
On 8/10/2010 10:42 AM, Nick Maclaren wrote: > In article<i3s1br$dks$1(a)speranza.aioe.org>, > glen herrmannsfeldt<gah(a)ugcs.caltech.edu> wrote: >> Vincenzo Mercuri<comp(a)lang.c> wrote: >> >>> I've been always told of the C language as the best choice >>> to accomplish any kind of task in numerical algorithms implementation. >> >> Who told you that? > > Someone seriously lacking in Clue? > >>> 3 -- what about the Standard IEEE 754 (IEC 60559:1989) conformance? >>> is that intrinsecal to the language or the implementation? >>> which language can offer a full support to the IEEE Standard, >>> C or Fortran? >> >> IEEE 754 (why 1989 and not 2008?) is not intrinsic to either, >> and likely neither offers full support. Fortran 2003 includes >> a module and many intrinsic functions, and those help write >> conforming code. Though not standard, many of the IEEE 754 features >> were available in C earlier than in Fortran. > > Neither offer full support, and the C support is seriously flawed, > much more than the slightly flawed Fortran support. Nobody who > has to ask this sort of question on a newsgroup has the chance of > a flea in a furnace of writing reliable numerical code using C's > IEEE 754 features, even ignoring portability (which is damn-near > impossible). I would have to sweat blood, and I know as much about > this area as anyone I know of. Agreed. > > Nobody supports IEC 60559:2008 yet, as far as I know, and it is far > from certain that it will get industry acceptance. It may simply > get kicked into the long grass by the community, in much the same > way that full C99 support has been. Full C99 support appears to be imminent from several additional support organizations, if you exclude 1 or 2 vendors who hope to force you into C++. Forget portability to the latter compilers. I defer to Nick on the prospects of 60559:2008. > >>> 4 -- what about performance? would you bet on C or Fortran? :-) >> >> I wouldn't bet. If you are careful in writing the appropriate >> low-level code in C, it can often be faster than Fortran. >> If you are not so careful, a good optimizing Fortran compiler >> might generate faster code, or it might not. > > Even if you are careful. Fortran is a vastly more optimisable > language than C, and beats the living daylights out of C on most > HPC systems, and usually when writing shared-memory parallel code. I've spent more time than is justified on such comparisons. It's usually possible to match performance of Fortran by choosing a good C99-ish compiler, devoting more effort (including additional continuing maintenance), and violating C subset usage recommendations of many experts. Compiler developers have devoted the additional effort needed to bring these C99-ish compilers up to par with Fortran; the supposedly larger market has been seen as justifying the extra effort. -- Tim Prince |