Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!dali.cs.montana.edu!uakari.primate.wisc.edu!aplcen!aplcomm!tedwards
From: tedwards@aplcomm.JHUAPL.EDU (Edwards Thomas G S1A x8297)
Newsgroups: comp.lang.apl
Subject: Re: ACORN, and other niceties
Summary: APL seems like natural SIMD language
Message-ID: <448@aplcomm.JHUAPL.EDU>
Date: 14 Jun 91 19:00:28 GMT
References: <1991Jun11.200234.6130@aplcen.apl.jhu.edu> <1991Jun13.044828.29504@yrloc.ipsa.reuter.COM>
Reply-To: tedwards@aplcomm.jhuapl.edu (Edwards Thomas G S1A x8297 )
Organization: JHU/APL, Laurel, MD
Lines: 26

In article <1991Jun13.044828.29504@yrloc.ipsa.reuter.COM> hui@yrloc.ipsa.reuter.COM (Roger Hui) writes:
About outer products in APL in parellel...
>On a serial machine, this takes time O m*n (and IS inefficient).     
>On a SIMD machine (like the Connection Machine), a straightforward
>translation of the algorithm yields:

> Propogate x and y to m*n processors                 O log m>.n
> Compute the m*n = operations of the outer product   O 1        [!]
> Compute the or-reduction                            O log n

>The total time taken is O log m>.n .  Log time is "speed of light";
>this "huge outer product" algorithm is in fact time optimal.

I have spent two years programming the Connection Machine, and my
favorite choice for a high-level language would be APL by far.
Having variables be vectors or matixes as naturally as scalars would be
immensely useful.  To make it really useful, though, one would have to
spend alot of time and carefully look at where systollic array algorithms
would speed it up (such as matrix multiplication).  

Unfortunately, this will probably never happen due to the MITheadedness
at TMC.  I'll admit, I myself had a prejudice against APL until I began
using it.  But one thing is for sure, APL is no sillier than
that wierd FORTRAN they have running on the CM.

-Tom