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: Luka Djigas on 30 Jun 2010 04:38 On Tue, 29 Jun 2010 23:54:02 -0500, Ron Shepard <ron-shepard(a)NOSPAM.comcast.net> wrote: >In article <7hpk26508f5u9upi2llp267c2lsrik0e5l(a)4ax.com>, > Luka Djigas <ldigas(a)get.rid.of.this.gmail.com> wrote: > >> Based on what criteria ? >> The last time I checked, Moore's law still holds. > >You know that Moor's law is about the number of transistors, not the >speed of the clock, right? > >$.02 -Ron Shepard Yes but still, it has always served as a good indicator of development.
From: glen herrmannsfeldt on 30 Jun 2010 10:49 Ron Shepard <ron-shepard(a)nospam.comcast.net> wrote: (snip) > Even though fortran does support these kinds of data structures, it is > often better to avoid them. Allocatable arrays in fortran, for example, > have several advantages over the analogous pointer approach, and that is > often the preferred data type given the various options. As far as I > know, even modern C does not support multidimensional allocatable > arrays, and it gives the programmer no control over the lower bounds > within the array, so it is some 30+ years behind fortran in some ways, > and 20+ years behind fortran in others. I don't know about the latest > version of the other languages in this thread title in this respect. I believe that C99 has variable dimension automatic arrays. I haven't tried them yet. -- glen
From: Ron Shepard on 30 Jun 2010 11:50 In article <i0fli7$hq9$1(a)speranza.aioe.org>, glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: > Ron Shepard <ron-shepard(a)nospam.comcast.net> wrote: > (snip) > > > Even though fortran does support these kinds of data structures, it is > > often better to avoid them. Allocatable arrays in fortran, for example, > > have several advantages over the analogous pointer approach, and that is > > often the preferred data type given the various options. As far as I > > know, even modern C does not support multidimensional allocatable > > arrays, and it gives the programmer no control over the lower bounds > > within the array, so it is some 30+ years behind fortran in some ways, > > and 20+ years behind fortran in others. I don't know about the latest > > version of the other languages in this thread title in this respect. > > I believe that C99 has variable dimension automatic arrays. > I haven't tried them yet. Can you allocate these multidimensional arrays with malloc() (or some other library routine) in the same routine that they are used? In older versions of C, malloc() would only allocate 1D arrays, and the programmer had to restort to various pointer tricks to mimic using it as a multidimensional array. And some of those pointer tricks were, strictly speaking, illegal in the language. As I said before, claiming that as a "feature" of the language is like trying to make a liability sound like an asset. $.02 -Ron Shepard
From: Gordon Sande on 30 Jun 2010 12:09 On 2010-06-30 12:50:38 -0300, Ron Shepard <ron-shepard(a)NOSPAM.comcast.net> said: > In article <i0fli7$hq9$1(a)speranza.aioe.org>, > glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: > >> Ron Shepard <ron-shepard(a)nospam.comcast.net> wrote: >> (snip) >> >>> Even though fortran does support these kinds of data structures, it is >>> often better to avoid them. Allocatable arrays in fortran, for example, >>> have several advantages over the analogous pointer approach, and that is >>> often the preferred data type given the various options. As far as I >>> know, even modern C does not support multidimensional allocatable >>> arrays, and it gives the programmer no control over the lower bounds >>> within the array, so it is some 30+ years behind fortran in some ways, >>> and 20+ years behind fortran in others. I don't know about the latest >>> version of the other languages in this thread title in this respect. >> >> I believe that C99 has variable dimension automatic arrays. >> I haven't tried them yet. > > Can you allocate these multidimensional arrays with malloc() (or > some other library routine) in the same routine that they are used? > In older versions of C, malloc() would only allocate 1D arrays, and > the programmer had to restort to various pointer tricks to mimic > using it as a multidimensional array. And some of those pointer > tricks were, strictly speaking, illegal in the language. As I said > before, claiming that as a "feature" of the language is like trying > to make a > liability sound like an asset. Have you ever talked to an accountant for a bank? Everything seems to get turned on its head! Their loan to you is an asset for the bank, since it is a liability for you and by double entry rules it has to be an asset on the other end of the transaction. Banks call the money you deposit with them liabilities under the same logic. It takes a bit of getting used to! > $.02 -Ron Shepard
From: Dogstar on 30 Jun 2010 12:20
"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. -DStar |