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 13 Aug 2010 05:06 In article <deOdnXbW48bCavnRnZ2dnUVZ7oidnZ2d(a)giganews.com>, Vincenzo Mercuri <comp(a)lang.c> wrote: > >I still need the power of C in system programming though. > >true...but 'handcoding assembly libraries' sounds a little scary :-) Hmm. Do you see the contradiction? I have done a lot of both, and I can assure you that the latter is a LOT easier than the former - at least if you give a damn about quality. Regards, Nick Maclaren.
From: Vincenzo Mercuri on 13 Aug 2010 05:15 Nick Maclaren wrote: > In article<deOdnXbW48bCavnRnZ2dnUVZ7oidnZ2d(a)giganews.com>, > Vincenzo Mercuri<comp(a)lang.c> wrote: >> >> I still need the power of C in system programming though. >> >> true...but 'handcoding assembly libraries' sounds a little scary :-) > > Hmm. Do you see the contradiction? > > I have done a lot of both, and I can assure you that the latter > is a LOT easier than the former - at least if you give a damn > about quality. well...yes, system programming in C is scary too... Mostly when taking account the plethora of POSIX variants.. I think we need to standardize the standards... What is extremely difficult is the level of abstraction you need to understand what is happening under the hood. And actually you don't have to guess when get your hands on assembly code. I learnt some assembly in the past, an early version of MASM...but i think i should brush it up and get acquainted with GAS. -- Vincenzo Mercuri
From: Vincenzo Mercuri on 13 Aug 2010 05:18 Vincenzo Mercuri wrote: > Mostly when taking account the plethora of POSIX variants.. *taking into account -- Vincenzo Mercuri
From: gmail-unlp on 13 Aug 2010 09:19 On Aug 13, 6:15 am, Vincenzo Mercuri <c...(a)lang.c> wrote: > Nick Maclaren wrote: > > In article<deOdnXbW48bCavnRnZ2dnUVZ7oidn...(a)giganews.com>, > > Vincenzo Mercuri<c...(a)lang.c> wrote: > > >> I still need the power of C in system programming though. > > >> true...but 'handcoding assembly libraries' sounds a little scary :-) > > > Hmm. Do you see the contradiction? > > > I have done a lot of both, and I can assure you that the latter > > is a LOT easier than the former - at least if you give a damn > > about quality. > > well...yes, system programming in C is scary too... > Mostly when taking account the plethora of POSIX variants.. > I think we need to standardize the standards... > What is extremely difficult is the level of abstraction > you need to understand what is happening under the hood. > And actually you don't have to guess when get your hands > on assembly code. I learnt some assembly in the past, > an early version of MASM...but i think i should brush it up > and get acquainted with GAS. > > -- > Vincenzo Mercuri Well, in terms of performance, I think the steps to follow are (short description, of course): 1) Look for the best algorithm 2) if you need better performance, look for optimized (maybe handcoded assembly) libraries and how to use them. Take into account there are some available: Intel MKL and/or IPP, AMD ACML, Sun HPC, as well as others, I think. Whether some library will be suitable for you will depend on the application, I think. 3) If you do not find any performance optimized library well suited for your application, look for handcoded optimizations such as loop unroll, loop tiling, and many (I think a lot many) others. Maybe some of them will be provided by your compiler, so you will need to know fairly deeply your compiler too. 4) If you need even better performance, handcoding assembly maybe the option to follow, but at this time I think you will not find it so scary, you already know almost everything else, and when looking at step 3) above you already have learnt a lot about assembly. Now, with highly available multiprocessing you have to consider parallel implementation too for better performance. So, at least steps 2)-4) are affected by parallelization, and sometimes step 1) too, I think. Again, step 2) is fairly simple since most (if not all) libraries include some threaded version (e.g. via OpenMP or pthreads). Well, currently there are a lot of performance improvement options, I think, and at the time you will need handcoding assembly it will not look so scary. Fernando.
From: Ron Shepard on 13 Aug 2010 10:55
In article <v8idncIixMK-kPjRnZ2dnUVZ8vednZ2d(a)giganews.com>, Vincenzo Mercuri <comp(a)lang.c> wrote: > Nick Maclaren wrote: > > In article<deOdnXbW48bCavnRnZ2dnUVZ7oidnZ2d(a)giganews.com>, > > Vincenzo Mercuri<comp(a)lang.c> wrote: > >> > >> I still need the power of C in system programming though. > >> > >> true...but 'handcoding assembly libraries' sounds a little scary :-) > > > > Hmm. Do you see the contradiction? > > > > I have done a lot of both, and I can assure you that the latter > > is a LOT easier than the former - at least if you give a damn > > about quality. > > well...yes, system programming in C is scary too... > Mostly when taking account the plethora of POSIX variants.. > I think we need to standardize the standards... > What is extremely difficult is the level of abstraction > you need to understand what is happening under the hood. > And actually you don't have to guess when get your hands > on assembly code. I learnt some assembly in the past, > an early version of MASM...but i think i should brush it up > and get acquainted with GAS. There is something in between using high-level language constructs and hand-coding assembly. An example of this is the ATLAS BLAS library http://sourceforge.net/projects/math-atlas/ This code uses a high-level language, C, but it is used in a very low-level primitive way. Basically, it is writing assembly language in C. There is relatively little compiler optimization that can, or should be done on that code. The hard part of hand-tuning assembly is eliminated through brute force tuning of the various parameters (in ATLAS, that includes tuning for the number of registers, the size of cache, loop unrolling, matrix subblocking, and things like that). After a piece of code is written, it is run for hours at a time on the target architecture in order to search for the optimal set of tuning parameters, and then that final result is distributed for use. Why was ATLAS done in C? I don't know definitely, but I think it is simply because it relies heavily on use of the C preprocessor. If you look at some of the routines, there are more lines of preprocessor code than there are executable code. The low-level C code that is there is simple and could have been done just as easily (or maybe even easier) in fortran. In fact, considering the aliasing problems with C (look at the code, it is explicitly checked), fortran is probably the more natural language for things like ATLAS. But the C preprocessor has always been an integral part of the C language, and as all of us fortran programmers here know, the fortran standards process failed to produce anything similarly useful for fortran over the past 30+ years. So ATLAS (and many other similar low-level utility programs) is written in C rather than fortran. Maybe Steve Lionel can comment on the Intel MKL library (which is distributed only in object form, not source code). I would guess it is done internally the same way: in C, with tuning parameters, making heavy use of the C preprocessor. This was not always the case for numerical libraries, and it may not be the case for some of them now. In the 70's, the original BLAS specification (and the reference implementation) was in fortran, despite the fact that most published pseudocode was written in something like PASCAL at the time. Other popular numerical libraries written in fortran (or fortran+assembler) included EISPAK, LINPACK, LAPACK, NAG, IMSL, and the Boeing library. Now I would expect at least some of this development effort to have shifted over to C, and, like ATLAS, not because of any high-level advantage of C over fortran, but rather because of the power and flexibility of the C preprocessor to tune low-level code (both manually and automatically). $.02 -Ron Shepard |