Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83; site noao.UUCP Path: utzoo!linus!vaxine!wjh12!genrad!decvax!decwrl!amd70!noao!allan From: allan@noao.UUCP Newsgroups: net.lang,net.physics,net.micro.pc Subject: Re: Why FORTRAN Message-ID: <352@noao.UUCP> Date: Tue, 19-Jun-84 12:57:19 EDT Article-I.D.: noao.352 Posted: Tue Jun 19 12:57:19 1984 Date-Received: Thu, 21-Jun-84 01:36:16 EDT References: <2735@ecsvax.UUCP> Organization: Natl. Optical Astronomy Obs. Tucson AZ USA Lines: 34 I would like to agree that fortran is a good language for number crunching type programs. Of course, for other types of programs it leaves a lot to be desired, but most/many/some/my scientific programs are just number crunchers. If you have a good optimizing compiler then they are hard to beat. One example with which I am particularly familiar: Dr. Richard James at Manchester has a large N body program to simulate spiral galaxies. It is very important to make this program run as quickly as possible since each run of the program takes several hours on a CDC7600 (this story is from the pre-Cray days). To try to speed up critical sections of the code he tried writing some routines in assembly language. He often found that he could not improve on the code that the compiler generated. I think that, inetia apart, there are some good reasons for keeping fortran around. These days the fastest computers have what might be loosely termed 'array processor' architectures, e.g. hardware vector operations (Cray & CDC205) and array processor add-ons for vaxes. To make the best use of the speed of these computers it is necessary to use a language that can easily take advantage of the hardware features. An advantage of fortran for this task is that it is a fairly simple language. I believe that it is the only language that has had optimization features included for the array processor architectures (of course, this is because it is the language that scientists use .... ). Languages such as C and Algol68 are very nice to use for non numerical applications where the (still) primitive character features of fortran are a real pain, but when you must have the greatest speed possible in a numerical application, you simply cannot beat fortran. Peter Allan Kitt Peak National Observatory Tucson, Az UUCP: {akgua,allegra,arizona,decvax,hao,ihnp4,lbl-csam,seismo}!noao!allan ARPA: noao!allan@lbl-csam.arpa