Fortran Vs C, C++, C#
in [Fortran]
|
Prev: practice online trading. platinum online trading. online trading worldwide. online trading which is best
Next: variant data type
From: Dogstar on 30 Jun 2010 12:21 "Steve Fry" <scfry(a)raytheon.com> wrote in message news:7XsWn.305$5N3.154(a)bos-service2b.ext.ray.com... .... > Since the CPUs on todays computers are not getting any faster (as was > promised 20 years ago), my main concern is what will crunch numbers > faster. .... > -- Steve F. Steve, you must have a particular type of number crunching in mind. Multi-core CPUs can perform certain types of number crunching (those that benefit from parallel calculations) faster than CPUs with less cores. My hunch is that your statement is based on the use of only a one or two-core CPU, or on code that was not written to use multiple cores, or on code that gets little benefit from parallel processing (like legacy code written without using a modern Fortran). My suggestion is to test your statement by writing a Fortran benchmark program that maximizes the use of a modern Fortran, and vectored processing, and then compare the time of a "this year" CPU (e.g., an AMD 12-core CPU) with one of a few years ago (e.g. a four-core CPU). If your job requires you to perform a lot of number crunching, and your company is unwilling to provide you with a system with more than four-cores, then I understand where your misconception about CPU speeds comes from. Perhaps your statement would be true if you replaced "CPUs on todays computers" with "CPUs on today's cheapest computers". Also, graphical CPUs (GPUs) have been demonstrably been getting faster--much faster. The latest AMD and NVidia GPUs are surpassing the teraflop barrier. You may have been ignoring graphics number-crunching when you wrote your statement, but that's where the big money is being focused (CGI and video games). My opinion on languages: Use one that you are comfortable with, is suitable for the job, and is maintainable. I do not think that one particlar language stands out. -DStar
From: Lynn McGuire on 30 Jun 2010 12:48 >> BTW, in a case of non-strongly typed variable names, Lynn is a He. > > Darn. Darn. Darn. Now that you bring it to mind, I recall making that > mistake before. I apologize. I'll try to avoid making that mistake a > third time. Having once had the notion stuck in my mind, it tends to > sneak back in. No worries ! In fact, I have been on a personal campaign to get the female users of "Lynn" to get more strongly typed by changing their names to "Lynne". My campaign has been a total and abject utter failure though as none to date are willing to change <g>. You would not believe how many letters I get to Ms. Lynn McGuire. It is a clue that they are spam and do not even get opened. Thanks, Lynn
From: Robert Myers on 30 Jun 2010 12:50 robin wrote: > "Steve Fry" <scfry(a)raytheon.com> wrote in message news:7XsWn.305$5N3.154(a)bos-service2b.ext.ray.com... > | "rfengineer55" asked this question: > | > What can Fortran do that C, C++, C# can't? > | > > | > Along similar lines where would Fortran be a superior chice over C, C+ > | > +, or C# > | > | Since the CPUs on todays computers are not getting any faster (as was > | promised 20 years ago), my main concern is what will crunch numbers faster. > > They actually are getting faster. > Yes, indeed, they are, because more transistors *are* useful for speeding up even nominally serial code, and computer architects are still coming up with more clever ways to use them. Which language is fastest? Assembly language, along with a deep understanding of the hardware you are using. Neither c nor Fortran is an adequate substitute for assembly language because you invariably have a compiler with its own idiosyncrasies between you and the hardware. It makes no sense to pursue the language issue as a determinant of speed, because an important prerequisite, a deep understanding of the hardware being used, is usually lacking. If you have a deep understanding of the hardware, you can usually work around compiler idiosyncrasies. Most people really aren't all *that* interested in raw speed, anyway, or they shouldn't be. A more meaningful questions is: in which language can I get the most useful work done in a given amount of time? Even that question isn't exactly on target, unless you don't care what happens to the code when it falls to someone other than you to maintain, extend, or even to use it. I'm in a position now where my c skills are sharper than my Fortran skills, but I'm still thinking that Fortran is probably the better choice for many things I do. I'm sure that, as others have pointed out, the various pros and cons have been aired ad nauseum, but I'm still curious as to what people think about and actually do with Fortran (particularly as opposed to c) right now. Robert.
From: dpb on 30 Jun 2010 12:58 Alois Steindl wrote: > helbig(a)astro.multiCLOTHESvax.de (Phillip Helbig---undress to reply) > writes: > >> Fortran programmers can write Fortran in any language. :-) >> > Hello, > just a small remark: > I remember this statement as > "Real Programmers write FORTRAN in any language". > Of course at that time "Real Programmers" usually meant Fortran > Programmers, but it was a more general description of old style > programmers. In this context Fortran means the "proper" tools for these > guys, who also > "don't write comments. The code was hard to write, it should be hard to > understand." > Best wishes > Alois AFAIK, the quotation originated in the letter to editor in Datamation years ago...a portion of the specific paragraph containing it follows-- "... Recently, however, a black cloud has formed on the Real Programmer horizon. It seems that some highly placed Quiche Eaters at the Defense Department decided that all Defense programs should be written in some grand unified language called "ADA" ((C), DoD). For a while, it seemed that ADA was destined to become a language that went against all the precepts of Real Programming-- a language with structure, a language with data types, strong typing, and semicolons. In short, a language designed to cripple the creativity of the typical Real Programmer. Fortunately, the language adopted by DoD had enough interesting features to make it approachable-- it's incredibly complex, includes methods for messing with the operating system and rearranging memory, and Edsger Dijkstra doesn't like it [6]. (Dijkstra, as I'm sure you know, was the author of "GOTOs Considered Harmful"-- a landmark work in programming methodology, applauded by Pascal Programmers and Quiche Eaters alike.) Besides, the determined Real Programmer can write Fortran programs in any language." The url I have bookmarked for the fun of it is at that has the full text is <http://www.pbm.com/~lindahl/real.programmers.html> Enjoy! :) --
From: Lynn McGuire on 30 Jun 2010 13:01
>> If the old Prime computers had a C compiler, it was probably >> written in Fortran. The whole operating system was written in >> a heavily extended fortran 66 until the 198? release which was >> rewritten in PL/1. > > It did have a C compiler whose principal merit was that porting > to it was a thorough test of the quality of your code. Integers > were 32 bits; pointers to integers were 32 bits; pointers to > character arrays were 48 bits. There were quite a few > eccentricities. 48 bit char pointer and 32 bit integer pointer, nasty ! When we ported our fortran to the IBM mainframe from the Univac 1108 in 1975, we ran into a major problem. All of the machines that we had supported to that date were 36 bits or more using 6 bit bytes. So, our hollerith had 6HABCDEF all over the place. We had to change that to 4HABCD plus 2HEF. It was a major effort to change. Lynn |