Programming Language for Supercomputers

14 Programming Language for Supercomputers RICHARD L. LOZES

Downloaded by AUBURN UNIV on December 26, 2017 | http://pubs.acs.org Publication Date: November 6, 1981 | doi: 10.1021/bk-1981-0173.ch014

University of Florida, Quantum Theory Project, Gainesville, F L 32611

Computer a r c h i t e c t u r e s have evolved over the years from the c l a s s i c von Neumann a r c h i t e c t u r e i n t o a v a r i e t y of forms. Great b e n e f i t s to operating speed have accrued. The major c o n t r i b u t i o n s to speed have been the i n t r o d u c t i o n s of parallel processors and of p i p e l i n i n g . For many years, these innovations were t r a n s parent to the programmer. For example, to program i n F o r t r a n to run on a CDC 6600 (1), one d i d not take cognizance of the e x i s tence of m u l t i p l e f u n c t i o n a l u n i t s , nor d i d one consider the I/O channels when w r i t i n g F o r t r a n a p p l i c a t i o n s f o r the IBM 360 s e r i e s (2). This was because the parallel processors were hidden behind appropriate hardware or software. Unfortunately, other machines have not been as easy to use. Any machine with v i r t u a l memory s u f f e r s performance degradation when page swaps are too frequent. Some p i p e l i n e d machines l i k e the TI-ASC (3) or the CDC Star-100 (4) have rather long setup times f o r t h e i r a r i t h m e t i c pipes. Multiprocessor machines l i k e the I l l i a c IV (5) are next to useless i f the programmer pays no a t t e n t i o n to the a r c h i t e c t u r e . These features a l l d i r e c t l y impact the user; they have not been e f f e c t i v e l y hidden by s o f t ware at any l e v e l . Improvement of t h i s s i t u a t i o n could r e s u l t i f compilers took on the burden of optimizing code so as to promote e f f i c i e n t hardware u t i l i z a t i o n . The reluctance of manufacturers to supply compilers f o r anything but F o r t r a n (or d e r i v a t i v e s thereof) has l a r g e l y blocked t h i s course. F o r t r a n i s a r e f l e c t i o n of the von Neumann a r c h i t e c t u r e . The programmer i s forced to t r a n s l a t e an algorithm to f i t the confines of von Neumann a r c h i t e c t u r e , and the compiler must then t r a n s l a t e that s e q u e n t i a l r e p r e s e n t a t i o n backward i n order to generate a p a r a l l e l r e p r e s e n t a t i o n . Lamport has cogently argued (6) that such procedures i n v a r i a b l y r e s u l t i n low e f f i ciency i n programming and i n execution. Among the c o n t r i b u t o r s to these i n e f f i c i e n c i e s are Fortran's demand f o r d e t a i l s (since i t i s not a h i g h - l e v e l language) and i t s l a c k of g l o b a l s t r u c t u r e (which leads to l o s s of information upon t r a n s l a t i o n i n t o F o r t r a n ) . F o r t r a n implementations i n t h i s category include S t a r - F o r t r a n (7)

0097-6156/81/0173-0237$05.00/0 © 1981 American Chemical Society

Lykos and Shavitt; Supercomputers in Chemistry ACS Symposium Series; American Chemical Society: Washington, DC, 1981.

238

SUPERCOMPUTERS

IN

CHEMISTRY

for for

the CDC Star-100, IVTRAN (8) f o r the I l l i a c IV, and CFT (9) the Cray-1. In another c l a s s are languages w r i t t e n f o r s p e c i f i c a r c h i t e c t u r e s , i n c l u d i n g CFD (10) f o r the I l l i a c IV, G l y p n i r (11), a l s o for the I l l i a c IV, and SL/1 (12) f o r the Star. Such languages are obviously not portable due to the small number of Star's and I l l i a c s i n the world, and thus do not represent a v i a b l e a l t e r n a tive. Indeed the l a r g e number of a v a i l a b l e a r c h i t e c t u r e s makes p o r t a b i l i t y of paramount concern; a s c i e n t i f i c language must be a r c h i t e c t u r e independent i f i t i s to be u s e f u l . The only languages r e l e v a n t to t h i s d i s c u s s i o n which have achieved a r c h i t e c t u r a l independence are Actus (13) and Bohlender's Pascal extension (14). Actus ambitiously attempts to denote the p o s s i b i l i t y of p a r a l l e l processing. I t s syntax forces the programmer to s p e c i f y the p a t t e r n of p o s s i b l e p a r a l l e l i s m . The compiler i s f r e e to u t i l i z e or ignore that information. From one point of view, Actus can be regarded as an extension of Pascal e x p l i c i t l y f o r s i n g l e i n s t r u c t i o n stream m u l t i p l e data stream a r c h i t e c t u r e which i s compatible with any e x i s t i n g machine. Bohlender's Pascal extension (14), on the other hand, i s a true h i g h - l e v e l language. I t does not address a r c h i t e c t u r e at a l l ; i t s only concern i s to implement algorithms. It i s limited to the domain of l i n e a r algebra, p r o v i d i n g vectors and twodimensional matrices over the i n t e g r a l , r e a l , and complex numbers, along with the necessary p r i m i t i v e operations. I t s modest goals allow one to do away with i n d i c e s when t r e a t i n g vectors and matrices as such. This i s h i g h l y d e s i r a b l e , s i n c e i t r e s u l t s i n programming at a much higher l e v e l than otherwise p o s s i b l e , and gives the greatest p o s s i b l e freedom to the compiler to produce e f f i c i e n t code i n p a r t i c u l a r implementations. One can w r i t e , f o r example, "A := herm(U)*B*U", where A, U, and B are compatible complex matrices, and herm(U) returns the Hermitean a d j o i n t of U. In t h i s paper I propose a h i g h - l e v e l language, M u l t i l i n , to t r e a t problems of numerical m u l t i l i n e a r algebra while taking advantage of the v e c t o r and matrix processing c a p a b i l i t i e s of supercomputers. M u l t i l i n i s f r e e from a r c h i t e c t u r a l assumptions, thus each r e a l i z a t i o n of i t i n the form of a compiler can produce g l o b a l l y optimal code. Further, M u l t i l i n b u i l d s on an e x i s t i n g s t r u c t u r e , i n h e r i t i n g c o n t r o l s t r u c t u r e s , I/O f a c i l i t i e s , and a general von Neumann framework, lendirig a c e r t a i n ease to i t s implementation.


1

Design

Philosophy

There are at l e a s t four h i g h - l e v e l d e f i n i t i o n s required i n programming: the problem, the procedure b l o c k i n g , the procedure i n t e r f a c e s , and the data s t r u c t u r e s . The f i r s t may be l e f t aside i n t h i s d i s c u s s i o n . A h i g h - l e v e l language should help the programmer concentrate on what i s to be done, rather than on how i t i s to be done (15). On the other hand, e f f i c i e n c y considerations



14.

LOZES

Programming

Language

for

Supercomputers

239

g e n e r a l l y d i c t a t e that the programmer give some d i r e c t i o n to answering the question of "how". Indeed, g l o b a l o p t i m i z a t i o n i s s t i l l best done by humans. C a r e f u l a t t e n t i o n to algorithm s e l e c t i o n and i t s concomitant data s t r u c t u r i n g and procedure b l o c k i n g i s probably the best approach to g l o b a l o p t i m i z a t i o n . "How" should be e x c l u s i v e l y defined by these s t r u c t u r e s . The r e s t of the programming task can be devoted to "what", with the compiler f i l l i n g i n a l l d e t a i l s , i n c l u d i n g r e g i s t e r assignment, addressing of r e a l and v i r t u a l storage, and l o c a l code o p t i m i z a t i o n . The design of a language should provide the means of d e f i n ing procedures, t h e i r i n t e r f a c e s , and the c o n t r o l of flow. These aspects have evolved s a t i s f a c t o r i l y , so that I intend to take them over from an e x i s t i n g language. Language design should also provide a r i c h v a r i e t y of data s t r u c t u r e s appropriate to the problems to be solved. These must be accompanied by the d e f i n i t i o n of operations on those s t r u c t u r e s , e x p r e s s i b l e i n a c l e a r and concise n o t a t i o n . To unburden the programmer f u r t h e r , caref u l d i s t i n c t i o n must be maintained between data and i t s representation. This i s important both to a i d c o n c e p t u a l i z a t i o n and to permit independence of a r c h i t e c t u r e . I t i s n e a r l y impossible i n a l o w - l e v e l language l i k e F o r t r a n wherein a l l objects such as l i n k e d l i s t s , s t r i n g s , and trees must be represented by a r r a y s . Furthermore, the d e f i n i t i o n s of data s t r u c t u r e s must be e x p l i c i t and i n v i o l a t e . For example, arrays are at t h e i r best when homogeneous — a l l elements are to be t r e a t e d e q u a l l y . Thus, p a r t i tioned arrays should be p a r t i t i o n e d by name, not by i n d e x i c a l r e l a t i o n s ; bordered arrays should have t h e i r borders stored separately. Bohlender's Pascal extension (14) p a r t i c u l a r l y w e l l exemplif i e s these c o n s i d e r a t i o n s . Numerical l i n e a r algebra using the n a t i v e Pascal matrix r e p r e s e n t a t i o n i s handled c l e a n l y and succinctly. Multilin Much of numerical computation i n chemistry revolves about numerical m u l t i l i n e a r algebra. By t h i s term I denote the manipul a t i o n of arrays whose dimension may exceed two. Mindful of Richard and Ledgard's admonition (16) that language design should never be o v e r l y ambitious, I propose only data s t r u c t u r e s , operat i o n s , and syntax f o r programming m u l t i l i n e a r algebra. Multilin exceeds Bohlender's Pascal extension i n two ways: i t s p r o v i s i o n f o r more than two dimensions, and i t s e x p l i c i t d e c l a r a t i o n of data r e p r e s e n t a t i o n s . In a d d i t i o n to the usual array r e p r e s e n t a t i o n which s t o r e s A ( i , j , k ) as A ( ( ( i - l ) n + j - l ) o + k ) , where A i s dimensioned (m,n,o) and A', (mno), M u l t i l i n provides representations taking advantage of s p a r s i t y and symmetry. Patterned s p a r s i t y such as that exhibi t e d by a band diagonal matrix can be treated through another matrix. Thus a band matrix, A, dimensioned ( n , r ) , with k lower 1


240

SUPERCOMPUTERS IN CHEMISTRY


f

codiagonals and m upper codiagonals i s mapped A ( i , j ) - > A ( i , j - i + k ) for i-k

Programming Language for Supercomputers

Recommend Documents