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: dpb on 10 Aug 2010 21:37 Vincenzo Mercuri wrote: .... > 4 -- what about performance? would you bet on C or Fortran? :-) .... I'd bet on the better algorithm... --
From: Giorgio Pastore on 11 Aug 2010 01:25 Paul van Delst wrote: > > gmail-unlp wrote: >> On Aug 10, 7:18 pm, Giorgio Pastore <past...(a)units.it> wrote: .... 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? > > The fact that f2003 compilers are still (!) not widely available? .... Precisely for that reason! However, I have to add that even the reduced support provided by existing compilers is enough for (at least) part of my current programming style. Of course, one has to understand that OO programming does not coincide with a specific language and every language has its own way to objects. Simply trying to set a 1-1 correspondence between C++ and Fortran statements would completely miss the point. However, I find quite disturbing the issue of the slow inclusion of new versions of the standard in the majority of Fortran compilers. Although I do not see a realistic solution, I think that in some way the standard committees should consider and taking into account more seriously such a point. Giorgio
From: Richard Maine on 11 Aug 2010 01:42 Giorgio Pastore <pastgio(a)units.it> wrote: > However, I find quite disturbing the issue of the slow inclusion of new > versions of the standard in the majority of Fortran compilers. Although > I do not see a realistic solution, I think that in some way the standard > committees should consider and taking into account more seriously such a > point. They do. They consider it very seriously, I assure you (and I have been in an excellent position to know). What that consideration turns into as an end result is perhaps not so evident, and not necessarily universally agreed, even within the committee. For example, I have publically disagreed with some recent committee decisions in exactly this area. (I'll not wander off into the details of that disagreement again in this thread.) But that doesn't mean that the committees don't take the question very seriously. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: Nick Maclaren on 11 Aug 2010 03:58 In article <8ce712Ffs1U1(a)mid.individual.net>, Tim Prince <tprince(a)computer.org> wrote: >> >> 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. Interesting. When I last looked, the only full support I found was in Sun ONE Studio 11 or later on Solaris 10 or later, and possibly only on a SPARC. I didn't check how well it worked, as I regard it as a demented idea in the first place. But that was a few years ago. I am surprised that you say "from several additional support organizations", as this needs some pervasive compiler and run-time system modifications. Even assuming the near-unusable level of IEEE 754 support that C99 specifies, and ignoring Annex G, with maximum contempt. >>>> 4 -- what about performance? would you bet on C or Fortran? :-) >>> >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. Interesting. My experience was that inter-procedural optimisation was critical for most real programs - with that, C was tolerable, but it was a major problem if crucial libraries were not available in source. But that was also a few years ago. Regards, Nick Maclaren.
From: Nick Maclaren on 11 Aug 2010 04:18
In article <i3sucp$jp0$1(a)speranza.aioe.org>, glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: >Ron Shepard <ron-shepard(a)nospam.comcast.net> wrote: >> 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. > >You can split the expression across statements with temporary >variables. I am not sure that Fortran is really that much better, >though. The interesting effects that come from some intermediates >being stored as temporary real (80 bit) where others are not >doesn't help much in many of those algorithms that depend on >expression ordering. Fortran is MUCH clearer - it says that this is processor dependent, and that's an end on't. C90 was different and a bit more confusing, and God alone knows what C99 specifies! The details of that lunacy are off-group, as well as off its rocker. >> Also, float arguments were promoted to double >> in all function calls, another troublesome feature when trying to write >> careful numerical code. > >I believe gone in C89 when a prototype is in scope, except for >varargs functions. In C89, all the math functions (sin, sqrt, etc.) >are only available in double precision, and are used with the >appropriate conversion. With systems that keep intermediate >results in extended precision it makes more sense that way. Er, no - see above, but this is a C90-ism, not a C99-ism. >> 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 usual array of pointers to arrays works pretty well in C, >but doesn't work so will with mixed C/Fortran code. No, they don't, as soon as you need a non-trivial matrix algorithm. This was one of the biggest nightmares in writing numerical libraries in Algol 60, and is why Algol 68 introduced slicing. Iliffe vectors work very well for some codes, and direly for many other important ones. >> 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. > >I believe fixed in C99, though I haven't used this yet. Nope. Little change. Nor in C++0X, nor in C1X. Variably modified arrays bring C99 up to about the level of Egtran (i.e. Fortran II with automatic arrays), but WG14 are considering whether to make both them and complex numbers optional in C1X. If anyone cares. Regards, Nick Maclaren. |