Re: [Bug-apl] miscellāneum

[Dr . Jürgen Sauermann]

On 02/28/2019 11:59 PM, Hudson Flavio Meneses Lacerda wrote:
...

=3= Optimization Questions

That is just of curiosity: how do the 10 efficiency suggestions by
Bergquist (p.34−37) apply to GNU APL?

I can confirm that the findings of Mr. Bergquist were correct at the time when he wrote
the book. But the development of CPU architectures and the explosion of memory sizes
has made most of these statements are obsolete.

As far as GNU APL is concerned, first of all apply statement 1. on page 38 to the interpreter
itself rather than to the APL code that is being interpreted. That will rule out quite a few
optimizations such as J vectors. I considered them briefly but came to the conclusion that
they were too rare in real life to justify any efforts in that direction.

Compiling APL is, IMHO, a dead end. I have written a number of compilers for other languages
myself, but APL is the last language for which I would consider it. The main reason is that the lack
of declarations makes it impossible to compile. The same defined functions can behave very
differently in different invocations. Consider the following defined function:

∇ FOO
[1]  A B C
∇

What GNU APL has, though, is the possibility to call C++ code from APL (native functions). And,
as of recently, you can even override the built-in primitive functions and operators of GNU APL.
That allows anybody else in this world to do better than I did.


In particular today I would argue that:

1. Wrong

2. Almost wrong

3. Wrong for GNU APL

4. Storage in ravel order remains correct; the rest is not

5. Correct

6. Wrong at least for GNU APL. GNU APL has no garbage collection but instead uses smart pointers.

7. Modtly correct. The fastest primitives in GNU APL are monadic ↑ and ⍬ and not ⍴.

8. I tend to measure time with a (CPU-)clock rather than a ruler. The remarks on scalars are partly incorrect in the context of scalar extension (e.g. multiplication of a vector and a scalar).

9. As general comment on optimization, one needs to consider not only the gains for specific examples
but also the overhead for (frequently failing) runtime-checks if the optimization is correct.

In the IA←A/⍳pA example, the interpreter cannot possibly know if A is an APL variable (in which case
the optimization is correct) or a niladic function (in which case the optimization could be incorrect).
So every time such an _expression_ is seen, the runtime-parser has to check for that case. One can
easily construct cases where a dramatic optimization could be made but for almost every such case a
counter-example can be constructed that prevents the optimization. For that reason GNU APL is fairly
careful when it comes to optimizations.