[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NadaNet 3.1 Released

mdj wrote:

On May 29, 12:13 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:

Hi, Matt!


Greetings :-)


(Of course, another barrier is having enough 'spare' Apple IIe
motherboards to build a 'Crate; I rationalised my collection and
probably want to keep the remaining IIe's 'intact'. If I happen upon
an auction for a large set and can bare the shipping expense, I'll add
them to (yet another) box.)

It's worth underscoring the fact that it is not necessary to disassemble
Apple II's to use them as part of a logical 'Crate.  NadaNet connects
all machines on the net as peers, and any can serve as a "board" of an
AppleCrate, if you will.

In fact, the AppleCrate is *only* a convenient mechanical packaging of
a number of //e machines.  It does make it necessary to deal with the
*inconvenience* of not having any attached I/O (except NadaNet) by
requiring that NadaNet boot ROMs be installed!  None of this is needed
for a "normal" Apple II.

Any Apple II with a game port can participate in a NadaNet as a full
peer simply by booting a NadaNet startup disk.  (It can then continue
to be used separately as a normal //e, participating in the network
only when: 1) a NadaNet command is entered manually or executed as part
of a program, or 2) the "service loop" is started on the machine so
that other machines can talk to it.


True enough. I guess I can find the desk space to stack a couple of
machines on.. Now to find my *desk* ...


...sounds like my desk.  ;-)

...

         As we've discussed, that problem is perhaps a generation
away from a sweet solution (likely involving new programmers to write
the new programs ;-).


I think you're probably right. There's been a couple of tentative toes
placed into the water by some - Apple's recent C compiler work for
instance has introduced 'blocks' (think closures) that can be passed
around as is the norm in functional languages, and the latest version
of MacOS can exploit multiple cores to realise the implicit
parallelism of evaluating a closure within the current execution
frame. The marketing name given to this is "Grand Central Dispatch"

(NB Real Grand Centrals like the one in NYC probably do a better job
of handling concurrency than the computing fraternity)


Since sequential programming already demands so much of our spatial
reasoning, I guess it shouldn't come as a surprise that there's so
little left over to consider time as a two dimensional quantity. My
own experience with parallel application development over the years
has taught me that even the most innocuous looking construct, say
using a mutex to serialise access to a resource (the proverbial
critical section) is fraught with hidden complexity.

Absolutely.  Most people underestimate the growth rate of N squared,
let alone N factorial!  The number of possible things that can happen
at even a mutex grows very rapidly with contention, and the best
algorithms for handling sequential re-use change, too.


For this reason, I'm almost convinced that many of the cores we're
about to sprout will end up doing static analysis to determine 'on the
fly' how to put the other cores to use.


Moore's "Law" density increases are certainly outpacing our abilities
to decompose computations into relatively independent concurrent parts.

Fifteen years ago, I was warning that this impasse, which essentially
stops the practical increase of PC performance, would mean an end to
the whirlwind of hardware replacement every 2-3 years, which would be
the end of rapid market growth and easy profits.

That seems to have played out on schedule, with the typical hardware
replacement cycle now having moved up to 4-5 years (or more).  Most of
the hardware growth is now in Asia.

The fizzling out of rapid PC replacement has taken enough years that
most of the industry has simply lowered their expectations (their
stockholders certainly have!).  With slower growth, Intel and Microsoft
now have to work harder for their profits.  Meanwhile, Apple is trying
to replace the "faster, cheaper" game with a fashion game--apparently
quite successfully.  Computing at Tiffany's.  ;-)

I just noticed that a MacBook sells for twice what a comparably
configured PC notebook sells for--amazing!  (I'm sure that some will
point out some wonderful luxury details of the MBP that are not in
the generic laptop, but none of those are meaningful to me if I'm
trying to write a paper, prepare a presentation, edit a photo, or
browse the web.)

...

It's fun to solve problems like this, but mainly because it *isn't*
easy!  As a result, it's probably not the best way for a NadaNet
programmer to get their feet wet.  ;-)


In my university days I tutored concurrent programming. We had the
students build a virtual 'widget factory' in which conveyors and
processing points where represented as message oriented queues and
threads. It was a fun contrived example, and students quickly
discovered that doing a 'fancy' real-time display of the factory
presented a more difficult problem than the simulation itself ;-)


The Message Server displays an animated histogram of the number of
messages in each of the first 23 queues.  This provides a nice
graphical display of the state of the computation (though the queues
are identified only by their hex number, so you have to remember
what each means ;-).

The RATRACE demo, in which 75 messages are passed around to random
recipients until they have each been passed 255 times, puts on quite
a show of randomly bouncing queue depths, until they all drain out at
the end.

If concurrency is implemented by message passing, then queue depth
makes a bottleneck quite obvious.

...


Sending an assembly or compilation to another machine raises the issue
of a common file system.  Although my File Server provides stateless
access, it does not support OPEN..(READ | WRITE)..CLOSE file access,
nor does it support sector- or block-level access.  It handles the
subset of ProDOS commands that do not require keeping state between
operations, for which the atomicity of command execution is sufficient
to ensure consistency.

As a result, it is well suited to supporting programs written to use
BLOADs and BSAVEs for disk I/O (which are quite sufficient), but it does
not support programs that depend on the existing DOS or ProDOS command
set beyond the stateless ones.

If the text editor (B)loads the file into memory and (B)saves it back
to disk, then it could easily be modified to do so using remote File
Server(s), which could then host the assembler(s) and/or compiler(s)
on its/their local file systems.  It would be a File Server that also
was an Assembler Server, for example.


Right. I was more thinking of a more esoteric approach where the text
editor would send 'delta' information to the message server, which an
assembler agent then subscribed to. In this way, the assembler agent
could incrementally 'assemble' each delta against the already accrued
symbol table, and send messages back which the editor could then use
to provide edit-time notification of errors/warnings.

Note that a 'delta' could be single line, a copy/paste chunk, or an
entire file that's just been loaded. a simple command could switch you
to the monitor, where your assembled work is quickly shipped to the
correct locations and your source shipped 'elsewhere' on the NadaNet
for quick recall when you're done testing.

The 'challenge' is in keeping and then storing assembly metadata
(symbols *and* their references) in a structure suitable for fast
lookup such that a delete/inserts ramifications can be quickly
calculated. I admit though, this is an ambitious undertaking and
there's a few different ways to skin the cat ...


Wow!  A fully incremental assembler would be quite interesting...
Because of the need to keep the cumulative location counter, it would
be necessary not only to move the code in memory to handle insertions
and deletions, but also to "run" the location counter, fixing up all
the dependencies.

Many years ago, I was involved in a fully incremental Algol compiler,
developed as a classroom exercise.  The data structures required to
handle all textual changes interactively were quite elaborate.  Consider
the effect of editing a BEGIN..END pair to alter static scoping!

Many developers of interactive tools simply take the brute-force
approach afforded by large memories and fast processors, and just
recompile the whole unit after each edit!  It's much trickier to
try to do the least amount of work.  ;-)


A Print Server could be similarly implemented, assuming that it was
only necessary to print disk files.  (Of course, many Apple II apps
are not structured to place a disk file between the app and its printer,
so that could also be an issue for existing apps.)

You raise an interesting point--I have one //e that is configured for
general use:  editing, software development, etc., with a CFFA.  I have
so far not set up another capacious machine as a slave to run larger
apps, like assembly and compilation.  This sounds like it could be fun!

It will require modifying an editor to do its file I/O using the File
Server, but that shouldn't be hard if it is reasonably structured...


I don't think modifying Merlin 8 to do this would be that tricky...


The more generic solution, providing patches to ProDOS and DOS to access
files stored on a remote machine, raises several issues (multi-machine
state, file and file system sharing, etc.) that I have chosen not to
address.  Perhaps someone more comfortable with the internals of these
OSs would like to try for something more general?


I would like to see this happen. I do worry though given the
synchronous nature of I/O on an Apple II that such a feature might
quickly become too powerful to be useful, if you know what I mean...


Exactly.  Block locks, anyone?

The fact that any change to any file causes updates to the global file
system data structures leads to high-traffic points of contention.

-michael

NadaNet 3.1 for Apple II parallel computing!
Home page:  http://home.comcast.net/~mjmahon/

"The wastebasket is our most important design
tool--and it's seriously underused."