Cross-talk Bug in Native APL 68000 Level II
CROSS-TALK BUG IN APL LEVEL II FOR THE POWER MAC
I want to alert users of APL.68000 Level II for the Power Mac (the
NATIVE code version)
to a potential source of inaccuracy and unpredictable behavior, and to
solicit the
community for accounts of any similar experiences in order to help
correct the problem
I'm facing.
The present version of APL Level II for the Power Mac (3.03L) exhibits
the very disturbing
property of cross-talk between concurrent APL processes, concurrently
running copies
of the application executing single processes, and between APL running
with some other
applications as well.
First, what do I mean by cross-talk. I have observed a particular APL
function to
fail, i.e. cease execution, or to lose accuracy, when a similar
function is run concurrently
in a multitasked environment. If, for example, one establishes two (or
more) tasks
and executes the test function alone in any of the workspaces, the
result is accurate.
If the function is executed in two or more of the workspaces, then the
results are
progressively inaccurate and sooner or later lead to a fatal error
condition. If
one starts the test function in workspace A, it runs accurately until
the companion
workspace B begins to execute a similar case, whereupon inaccuracy
generally sets in
after a few cycles. If B is started, it runs accurately until A
begins. If A and
B are running together and getting progressively inaccurate, then
stopping either
A or B lets the remaining function return to accurate operation. It
would appear
that these NOMINALLY INDEPENDENT computations are influencing each
other. This cluster
of symptoms is what I mean by cross-talk.
Second, there is no logical basis in the source code for this behavior.
The functions
I have seen do this are fairly complicated, but consist only of basic
floating point
and integer operations. Their particular susceptibility to whatever
bug is causing
the cross-talk may arise from the use of large arrays, large temporary
(unnamed)
variables, and the use of an iterative solution scheme, but there is no
doubt that,
when run alone, any one such computation will converge to a unique
result to full
machine precision. Needless to say I am going to try and create a
simpler set of
test codes for the purpose of isolating this apparent error in the APL
interpreter,
and of course any suggestions would be welcome.
Third, make no mistake, this behavior is apparently unique to the
NATIVE code version
of the APL interpreter executing on a Power Mac -- a 7100 in my case.
The cross-talk
test discussed above will show NO DEGRADATION in performance when done
with:
(1) APL Level II (68000 version) on a Quadra series machine,
(2) APL Level II (68000 version) in EMULATION mode on a Power Mac, or
(3) APL Level I (68881 version) on a Quadra series or older (e.g.IIx)
platform.
Fourth, all attempts to recover normal operations by changing the
system configuration
have proved worthless. The phenomenon appears to be unrelated to the
spectrum of
extensions placed in service at boot time. The cross-talk also appears
to allow
the APL computation to be polluted by the action of other applications
(an FTP transfer
via FETCH 2.1.2 for example). A minor change in the cross-talk pattern
is observed
when I run two or more full copies of the native interpreter (viz.
APLa, APLb, APLc),
each executing a single test function in a single task environment. In
this situation
the front-most window seems to run longer without interference, while
backgrounded
windows become polluted within a few cycles.
Clearly MORE TESTING IS REQUIRED, and I am very interested in hearing
about similar
experiences with the native mode interpreter. For any users who are
interested,
the best home grown test functions would be relaxation methods which
converge to
some fixed point and operate on large (>1000) arrays of data. When the
cross-talk
emerges I suspect that any of the normal convergence measures will
reverse their
progression to zero.
A present I would not trust any NATIVE APL 68000 II calculation done
(a) with other
applications running, or (b) in a multi-tasked NATIVE APL 68000 II
environment, unless
that calculation was self-checking.
With comments, examples, refutation, or SOLUTIONS to this mess, please
contact:
Dr. Robert E. Terry
Radiation Hydrodynamics Branch, Code 6720
Naval Research Laboratory
Washington D.C. 20375
(202) 767-6782
