Frank Leonard writes:

I have been attempting some constuctions of finite groups in GAP as
defined by a presentation in abstract generators/relators.
The problem consists of applying a certain algorithim to constuct a
group which I then attempt to identify. I also have access to the C.A.
package CAYLEY and have re-written the algorithim for CAYLEY. I have
found CAYLEY to be vastly superior (time wise) to GAP for this problem.
I assume that the fact that GAP programs/functions are interpreted
would be significant in explaining the performance discrepancies but I
am curious if there are any other factors which might be significant.
Can you tell me if there are any plans at present to write a compiler
for GAP?

I am sorry that we cannot really answer such an unspecified (but
nevertheless very critical) letter, much as we try to react to
criticism brought to our attention in the GAP-forum (or otherwise).
Frank Leonard has not told us what kind of problem he is really
looking at, nor which GAP functions he has used, nor even which
version of GAP.

There are of course functions for which the fact that they are
interpreted rather than originally written in C and compiled mean a
loss of efficiency. We know that this can in particular be the case
with functions which deal in a rather combinatorial way with small
data, as is the case with many functions handling presentations. For
this reason some of the functions for dealing with presentations have
parts in the kernel to circumvent this difficulty. If the
interpretation of GAP functions was the reason for inefficiency that
Frank Leonard has observed then it would be helpful for us to know,
*how* big the loss of efficiency was in his case for which functions,
e.g. in comparison with CAYLEY. It is not helpful just to be told
that CAYLEY was *vastly* superior for some function(s?) that are not
named applying "a certain algorithm" that he does not care to tell us
about.

It is also likely that for certain functions we are using genuinly
worse methods than CAYLEY (for others we may use better ones). Then we
want to know even more where this is the case in order to be able to
improve them.

We are not only open to but ask for constructive or at least well
specified criticism, but I must say that a letter like that of Frank
Leonard is not only unhelpful but rather discouraging.

Joachim Neubueser

PS. I have said already in a previous letter to the GAP-forum that the
idea to develop a compiler for GAP is being considered, but that, if
at all, a compiler cannot be expected in the nearer foreseeable
future.