From: andrew@rentec.com (Andrew Mullhaupt)
Newsgroups: comp.lang.apl
Subject: Re: Numerical Analysis + APL/J
Date: 13 Aug 92 14:34:36 GMT
Organization: Renaissance Technologies Corp., Setauket, NY.

In article <1992Aug12.043633.22495@yrloc.ipsa.reuter.COM> rbe@yrloc.ipsa.reuter.COM (Robert Bernecky) writes:
>In article <1167@kepler1.rentec.com> andrew@rentec.com (Andrew Mullhaupt) writes:
>a. loop overhead: This is associated with interpreters, and some are worse
>   than others. Switch to a compiler.

Aren't any good enough now. Next question.

>b. The line just below here (Won't fit in cache) has nothing to do with
>   language design, but rather with hardware design. In particular,
>   it presumes that all caches are wonderful AND that they'll never be
>   big enough. Both assumptions are (for different reasons) false.
>   And, both have nothing more to do with APL than with any other language.

No. Won't fit in cache has a lot to do with language design. If you need
to set up your problem because your hardware has a cache, then you can't
much enjoy a language which frustrates this aim. The job of the language is
to provide as much comfort to the programmer without preventing the full use
of the underlying machine. It is quite possible for languages which do not
provide the actual addresses of objects to the programmer to 'build in'
intractable cache conflicts, or TLB conflicts.

All caches wonderful? I never presumed this. What I presume is that if you
have a cache on your hardware, it makes sense to avoid perverse alignment,
etc., which can give up a lot of the performance which sold you the machine
in the first place.

An example of a language which has had problems with caches, etc., is
FORTRAN. You will find that about 25% more performance is avaiable on
typical RISC workstations by using special preprocessors which resolve
this kind of problem. For a detailed analysis of how algorithms need to be
cognizant of the underlying hardware, see Golub and van Loan's _Matrix
Computations_. There is a useful discussion of how block structured linear
algebra can be advantageous in the presence of a cache. Languages which
provide matrix computations to the user in a 'shrink wrapped' form should
be aware of these considerations.

>Umm, that's why people set comparison tolerance to zero. The comparisons
>are not weirdo, merely different from computer hardware weirdo.
>Setting it to zero gives you computer hardware weirdo.

Yes, but your hardware vendor has been prevailed upon in most cases to
have implemented IEEE floating point, in which case you have quite a good
idea what the behavior is, and that it is a behavior which numerical analysts
arrived at after a ten-year struggle in the literature. You even have some
slight choices, which are sensible. This is why quad CT should generally
be set to zero. However, it's pretty annoying to set this in all of your
algorithms just to prevent some user from breaking the code.

>>mapped variables I won't be using APL anytime soon. Splus gives me this,
>>and that makes up for what (if it were APL) might very well be record
>>breaking sloth.
>
>What's Splus? (EMail is OK). Bob

Splus is a product of StatSci, Inc. It is a value added binary version of
AT&T's language S, which is the de facto standard of academic statistical
computation. The language has a lot of array manipulations, and built in
graphics, etc. Other than that it is a sad aggregation of disconnected
language elements, and certain extremely painful design errors. It can
look a lot like C, sort of. The reason it's useful to me is the dynamic
loading, which allows the user to have a full bandwidth way of not having
to live with the mistakes of the original designers.

Later,
Andrew Mullhaupt
Newsgroups: comp.lang.apl