Learning Fortran
in [Matlab]
|
From: Walter Roberson on 26 May 2010 10:01 dpb wrote: > And, I'll note that the vector notation of both Matlab and Fortran in > the source code will be turned into the same DO loop by the compilers > for execution and as would also be done by a C or Cpp or virtually any > other optimizing compiler language. Not if you are using a Single Instruction Multiple Data (SIMD) architecture with a sufficiently wide data list. The Intel SSE3 architecture is SIMD (but not especially wide.)
From: Steve Amphlett on 26 May 2010 10:13 dpb <none(a)non.net> wrote in message <htj3ae$e9e$1(a)speranza.aioe.org>... > > And, I'll note that the vector notation of both Matlab and Fortran in > the source code will be turned into the same DO loop by the compilers > for execution and as would also be done by a C or Cpp or virtually any > other optimizing compiler language. > > -- Matlab started out life as a wrapper around FORTRAN. Isn't it nice that FORTRAN is morphing into Matlab now?
From: dpb on 26 May 2010 10:19 Walter Roberson wrote: > dpb wrote: > >> And, I'll note that the vector notation of both Matlab and Fortran in >> the source code will be turned into the same DO loop by the compilers >> for execution and as would also be done by a C or Cpp or virtually any >> other optimizing compiler language. > > Not if you are using a Single Instruction Multiple Data (SIMD) > architecture with a sufficiently wide data list. The Intel SSE3 > architecture is SIMD (but not especially wide.) Well, yes, I left out multiple cores and such other hardware but the point is that compilers will all generate essentially the same instruction set for a similar set of operations (for a specific set of hardware) irregardless of the source code format (as long as one uses optimization switches and doesn't do specific tricks that prevent optimizations). Essentially the same thing w/ loops as you pointed out earlier about jump tables and switching constructs--it all has to translate back to the instruction set and what's effective there is dependent on the hardware and instruction set available, number of registers, etc., etc., etc., ... So, not surprisingly, whatever the source form, similar constructs end up being implemented in similar fashion whatever the language. Way back on the CDC, there was loop unrolling and automagic parallelization of DO loops to take advantage of the installed hardware. Any given machine had it's own number of vector registers (depending on how deep the customer's pockets were :) ). Have cousin who worked for CDC in MN in support of the FTN compilers. A task was to modify to match the hardware for the various installations. The point is for folks to not get so bound up in what the source language is... --
From: dpb on 26 May 2010 17:04 Steve Amphlett wrote: > dpb <none(a)non.net> wrote in message <htj3ae$e9e$1(a)speranza.aioe.org>... >> >> And, I'll note that the vector notation of both Matlab and Fortran in >> the source code will be turned into the same DO loop by the compilers >> for execution and as would also be done by a C or Cpp or virtually any >> other optimizing compiler language. >> >> -- > > > Matlab started out life as a wrapper around FORTRAN. Isn't it nice that > FORTRAN is morphing into Matlab now? Yes, indeed, altho I think there are limitations owing to compatibility that will limit the progression. The biggest difference will, I think, continue to be that won't be able to overload operators to make things like "*" be matrix multiply so will either have to write own generic interfaces for cases where can and not sure how far one can actually go in that regards. But, it is certainly "not your father's FORTRAN" any longer, for sure. :) --
From: James Tursa on 26 May 2010 18:33
dpb <none(a)non.net> wrote in message <htk2h9$4rg$1(a)news.eternal-september.org>... > > The biggest difference will, I think, > continue to be that won't be able to overload operators to make things > like "*" be matrix multiply so will either have to write own generic > interfaces for cases where can and not sure how far one can actually go > in that regards. Yes, you can't overload "*" to be matrix multiply for built-in type arrays like arrays of real, but you can overload "*" to be a matrix multiply for a user-defined type, and you can always create a brand new operator to do a matrix multiply so you could write something like A.mmult.B to get a matrix multiply for real types A and B. In defense I would note that other OOP languages like C++ don't allow overloading the built-in operators for intrinsic types either. James Tursa |