brooks@lll-crg.ARPA (Eugene D. Brooks III) (04/01/85)
After a lot of procrastination we are finally going to get a Vectorizing C compiler for the Cray computers for those interested in doing numerical work in the C language. Just think, a C program running at 160 megaflops. This will be great! A committee at LLNL has studied the language and its suitability for numerical work and is implementing the full C language with one minor modification. In order to have compatibility with Fortran all subroutine parameters will be passed by address. A small price to pay for good floating point performance don't you think?
rkl@ahuta.UUCP (k.laux) (04/02/85)
REFERENCES: <486@lll-crg.ARPA> What do you mean, "minor" change of passing all arguments by reference (correct term, not address) to maintain Fortran compatibility. What are POINTERS for. You can realize the same effect using them. R. Kevin Laux Vendor Tech Support ATTIS Lincroft, NJ ahuta!rkl
kjm@ut-ngp.UUCP (Ken Montgomery) (04/03/85)
[] From: brooks@lll-crg.ARPA (Eugene D. Brooks III) >After a lot of procrastination we are finally going to get a Vectorizing >C compiler for the Cray computers for those interested in doing numerical >work in the C language. Just think, a C program running at 160 megaflops. >This will be great! Sounds like fun! (Not to mention useful!) >A committee at LLNL has studied the language and its suitability for numerical >work and is implementing the full C language with one minor modification. >In order to have compatibility with Fortran all subroutine parameters will >be passed by address. A small price to pay for good floating point performance >don't you think? No. What you have after that modification is no longer C. To wit, K&R has a *whole section* (#1.8, on page 24) titled "Arguments - Call by Value". Call-by-value is justified as follows: ... because arguments can be treated as conveniently initialized local variables in the called routine. I submit that many, many programs take advantage of this feature, so the change to call-by-reference would break a large amount of existing software. In addition, call-by-reference is unsafe, since one has no idea what a routine loaded from someone else's object library does to its arguments. (Yes, I know one can program around this, but the work-around is a crock.) As already mentioned, call-by-reference can be simulated where necessary with pointers (or you could define the 'fortran' keyword as a way to force call-by-reference to individual functions). -- The above viewpoints are mine. They are unrelated to those of anyone else, including my cats and my employer. Ken Montgomery "Shredder-of-hapless-smurfs" ...!{ihnp4,allegra,seismo!ut-sally}!ut-ngp!kjm [Usenet, when working] kjm@ut-ngp.ARPA [for Arpanauts only]
outer@utcsri.UUCP (Richard Outerbridge) (04/04/85)
Speed sure sounds good, but I would hardly describe the price as small, the modification minor, or the resulting language 'C'. A commitee you say? -- Richard Outerbridge <outer@utcsri.UUCP> (416) 961-4757 Payload Deliveries: N 41 39'36", W 79 23'42", Elev. 106.47m.
nather@utastro.UUCP (Ed Nather) (04/04/85)
>>A committee at LLNL has studied the language and its suitability for numerical >>work and is implementing the full C language with one minor modification. >>In order to have compatibility with Fortran all subroutine parameters will >>be passed by address. A small price to pay for good floating point performance >>don't you think? > > No. What you have after that modification is no longer C. To wit, K&R > has a *whole section* (#1.8, on page 24) titled "Arguments - Call by > Value". > Ken Montgomery "Shredder-of-hapless-smurfs" I agree. It sounds like the work of a committee, all right. They should stick to something safe, like designing horses. Maybe you could call the new language C-minus. -- Ed Nather Astronony Dept, U of Texas @ Austin {allegra,ihnp4}!{noao,ut-sally}!utastro!nather
gwyn@Brl-Vld.ARPA (VLD/VMB) (04/06/85)
It's also not clear that a "vectorizing C compiler" makes much sense, given the form of typical C code.
brooks@lll-crg.ARPA (Eugene D. Brooks III) (04/07/85)
> It's also not clear that a "vectorizing C compiler" makes > much sense, given the form of typical C code. For the traditional uses of C, operating systems programming, compilers, text editors ... a vectorizing C compiler indeed does not make much sense. C is not restricted to the above uses and it is a very good language for numerical applications (modulo the float-->double problem that is being fixed in the ANSI standard and has been fixed in any compiler that I have used for numerical work). I have been using C for numerical programming for 4 years now. Fortran used to be the only language I used and I have not used it for 4 years. I have even forgotten some of the key words. I am not an isolated case as there is a small but growing community of scientists who are using C instead of fortran for their work. The data structures that can be created in C make the layout of a typical program much cleaner and more easily understood. It is clear that for C to be used for numerical work on supercomputers one must have a vectorizing C compiler just as is the case for Fortran. Consider the code below. float **a, **b, **c; int dim; int i,j,k; for(i = 0; i < dim; i += 1) { for(j = 0; j < dim; j += 1) { a[i][j] = 0.0; for(k = 0; k < dim; k += 1) { a[i][j] += b[i][k] * c[k][j]; } } } Considering the inner loop one can see that a vector dot product is being formed. The fetch of b[i][k] is a stride 1 vector fetch. The fetch of c[k][j] is a gather fetch using an offset of j from the array of pointers c[k]. This loop will vectorize on the Cray XMP48, the Cray 2, the CDC 205, and the Convex C-1 among others. So why not have a vectorzing C compiler avaiable to the users of C on these machines? The only valid argument against the use of C for numerical work on supercomputers is the lack of a vectorizing compiler. A "vectorizing" compiler, where one means that the compiler unrolls loops to reduce the jump overhead and picks the best possible way to get the work done on a given machine is even useful on a scalar machine such as a VAX. As an example consider the following trick that I have in fact used frequently to get vector operations to run is fast as is possible on a VAX. void vdadd3(a,b,c,dim) double *a, *b, *c; int dim; { /* Leaving out the code to take care of the dim%N extra elts. */ dim /= N; do { *a++ = *b++ + *c++; *a++ = *b++ + *c++; . . . *a++ = *b++ + *c++; *a++ = *b++ + *c++; } while(--n > 0); } Just how big you can make N on a vax is determined by how big the cache is. At around N == 16 the instruction fetches start causing cache misses. Wouldn't it have been nicer to have simply written vdadd3(a,b,c,dim) { int i; for(i = 0; i < dim; i += 1) { a[i] = b[i] + c[i]; } } and have the compiler pick up the the vector operation and put in all the pointer crazyness and the loop unrolling! In this context a vectorizing compiler is even useful on a scalar machine.
radford@calgary.UUCP (Radford Neal) (04/08/85)
>A committee at LLNL has studied the language and its suitability for numerical >work and is implementing the full C language with one minor modification. >In order to have compatibility with Fortran all subroutine parameters will >be passed by address. A small price to pay for good floating point performance >don't you think? > (Insert lots of comments posted about the resulting language not being C.) The reaction to this MAY be premature. One could write a C compiler which passed parameters by the address of a temporary location which has been set to the value of the actual parameter. I.e. the call fred(x,1); would be compiled as t1 = x; t2 = 1; fred(&t1,&t2); Assuming corresponding dereferencing when the parameter is accessed, this is just a rather inefficient way of implementing call-by-value and would not make the language "not C". This might be justified by the ability to call a FORTRAN routine like fred(x,1); without having to manually convert it to t = 1; fred(&x,&t); and without having to declare it as being a special FORTRAN routine. Of course, this only works if the FORTRAN routine doesn't return information in its parameters (i.e. if it is essentially treating parameters as call-by-value). This would be true of many numerical routines (e.g. SQRT). Of course, if this ISN'T what the original poster meant, I would certainly agree that the language isn't C. Radford Neal The University of Calgary
cottrell@NBS-VMS (04/12/85)
/* > It's also not clear that a "vectorizing C compiler" makes > much sense, given the form of typical C code. That's the whole point. If we're gonna get these number crunchers to use our beloved language, we gotta make it as attractive as FORTRASH. jim cottrell@nbs */
brooks@lll-crg.ARPA (Eugene D. Brooks III) (04/25/85)
I guess that its time to let this razz die! The original article for this was indeed posted on April 1. Due to the large amount of flaming responses another member of the committee (who bears responsibility for the joke in the first place) decided to add some fuel to the fire. It is true that a C compiler is being developed for the Cray 1 here at LLNL. The compiler is being developed as a front end for the final pass of the current Fortran compiler where vectorization and optimization is done. Hence vectorization will come for free and is for the most part incidental. It will be very much appreciated by numerical C users like myself. The pass by reference statement was an April 1 razz. No one here would think of doing such a thing to the C language (I hope).