Cross-talk Bug in Native APL 68000 Level II 
Author Message
 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




Tue, 01 Apr 1997 13:15:45 GMT  
 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 MicroAPL correct the problem.

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.  I am making some progress on 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, 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, or the use of POPmail at the same time, 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, unless the calculation is self-checking, 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.

With comments or examples,  please contact:

Dr. Robert E. Terry
Radiation Hydrodynamics Branch, Code 6720
Naval Research Laboratory
Washington D.C. 20375
(202) 767-6782




Thu, 10 Apr 1997 11:45:22 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. Product Announcement - APL.68000 Level II for Mac and Power Mac

2. APL.68000 Level II for Mac experience?

3. APL.68000 level II?

4. I-APL, Vanguard APL, and APL.68000

5. Porting APL*PLUS/PC to APL.68000

6. APL for 68000; MAC APL

7. 68000 Native Forth

8. F68K - a native code Forth for 68000

9. 68000/486 cross assembler

10. 68000 Modula-2 Cross-Compiler for the PC?

11. APL.68000 for Macintosh

12. GEM and MIDI using APL.68000; help

 

 
Powered by phpBB® Forum Software