Re: Xy III & Faulty Memory?

[Robert Holmgren holmgren@xxxxxxxx]

** Reply to note from xywrite@xxxxxxxx Mon, 26 Oct 1998 15:48:07 -0500 (EST)

> ≪ Use backward, not forward, references--that's a no-no
> with interpreted languages≫

> Could you let us know where you read that?

When I say "interpreted", I simply mean as opposed to "compiled". In the
80s, the "no forward reference" rule was often mentioned (especially in
connection with "structured programming" as opposed to spaghetti code), and
I always kept it in some corner of my mind, even if I didn't always follow
it. (Obviously, there are trade-offs of economy vs. speed and memory,
which you mention -- but in almost all cases, even if my method appears
prolix, it _will_ be faster; indeed, I can't think of any method which is
slower than using LaBels in code architecture!) Nested "IF...ENDIF"s and
SUbs -- separately introduced into Xy3 at different stages of its evolution
-- made structured programming more possible (in recent years, I've tried
to avoid LaBels altogether, and just use nested conditionals wherever
possible).

There were, as I recall, two empirical proofs. And there are
really two issues here, not always easy to separate. One is speed of
execution, the other is memory consumption. When I ran Xy3 on a DOS
machine, I often resorted to a DOS utility called MEMWALK, which displayed
the entirety of the memory space, low and (if I recall correctly) high
also. What it showed was _two_ copies of any program in memory. One copy
was the whole program, as written; the other was a tokenized version of the
code that had executed, up to the point of termination (including pointers
to current values of Save/Gets, etc). You could branch out of a program in
the midst of it, shell to DOS, and call MEMWALK to examine the (currently
suspended) memory state of the parent program. I learned an amazing amount
about how XyWrite worked from MEMWALK, e.g. the codes written to the screen
-- but invisible -- that triggered various on-screen video modes like BO or
UL (all 6-bytes long, & beginning with Ascii-252). And I played a lot with
disassemblers, as a learning tool.

The second proof was to write a program like the following, then use a set
of crude timer programs (TIMERBEG and TIMEREND) to measure execution times.
Xy4 has a very concise timer program (by Carl) called "Iterate", which does
the same thing only far more efficiently and precisely than my old Xy3
programs. You need a shell to start:

;*;
;*;
;*;
;*;
;*;
;*;
;*;
;*;
;*;
;*;
;*;
;*;
;*;
;*;
;*;
;*;
;*;
;*;
;*;
;*;
;*;
;*;
;*;
;*;
;*;
;*;

With Iterate, you define the code you want to run (i.e. all lines from
LaBels A to Z), then command "Iterate 10000". This runs the code
10000 times, then reports the total elapsed execution time. You need to do
repeated runs of each test, to allow for memory caching and unpredictable
multitasking of background processes. Let's do five easily-reproducible
tests:

Insert  after 
 Mean time: 1.17 secs, max deviation=.01 secs
Insert  after 
 Mean time: 2.24 secs, max deviation=.01 secs
Insert  after 
 Mean time: 3.49 secs, max deviation=.03 secs
Insert  after ; put  after .
 Mean time: 3.68 secs, max deviation=.02 secs
Insert  after ; put  after .
 Mean time: 5.95 secs, max deviation=.04 secs

What can we conclude? Keeping in mind that these numbers represent ten
thousand iterations of an operation, there's a little more than a second of
overhead just getting going (mostly attributable to Iterate). There's
about .07 secs of overhead between each iteration. Then we assign about
.09 seconds to reading each LaBel -- _exactly_ quantifiable. First of all,
we have proof that in jumping from LBA to LBB, the program does not waste
time reading unnecessary LaBels C through Z. Jumping from LBA to LBM or to
LBZ simply extends the time by the precisely predictable amount that it
takes to read additional LaBels. Second, when we compare the last two
tests, we see proof that in jumping from LBA to LBZ and then to LBB _or_
LBY, EDITOR goes back to the _top_ of the code block a second time and
reads all the bloody LaBels from the very beginning to the end again, until
it hits LBB or LBY. A compiled or tokenized program would simply make the
jump, near or far, to a pre-compiled location in memory. XPL does not do
that. This is the behavior of an interpreted language.

All of which is to say, that what appears "economical" in terms of language
may in fact be terribly costly in terms of parsing and execution. People
who like to use lower case in things like  may simply be wasting
processor time because EDITOR has to convert it to upper case. People who
think ==0> is tidier than <1> may not realize that it is
far easier for an interpreter to reach greater-than or less-than decisions
than to resolve equivalence, which always raises questions for a computer
about degrees of precision (there is no such thing as absolute equivalence
for computers).

Enough of this stuff...


-----------
Robert Holmgren
holmgren@xxxxxxxx
-----------