Re: NadaNet 3.1 Released

[mdj <mdj.mdj@gmail.com>]

On Jun 1, 4:31 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:

> > 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.  ;-)

It's interesting just how long it took for everyone else to notice the
shift.

> 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.)

"Apples to Apples" the difference seems to be about 40% at the lower
end, swells a little in the mid range, then drops to very close at the
high end. Of course, each of Apple's offerings is a premium product in
its market segment and if you make the comparison point say "15 inch
laptop" you can certainly beat their pricing by 50% or more.

Given how many people use computers for just the small list of
utilitarian tasks you mention, it will be interesting to see how
successful the iPad is at capturing that market. It certainly closes
the cost gap, and the "closed + less flexible" perspective can also be
a "simpler + more reliable" perspective. My mother for instance barely
touches her laptop, but is literally drooling over the iPad. Her
eyesight is failing her and the "pinch zoom scroll" touch interface
for reading books is a *huge* drawcard.

My prediction is that iPad-alike devices will destroy the market for
cheap generic laptops over time and if Apple capture even 1/4" of that
market, they'll be a lot better positioned than they are now.

> >> 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.

Absolutely. It's my favourite way of implementing parallelism for
exactly that reason, and it's proven itself over time to be scalable
as long as you find the right intercept point for the queue :-)

> >> 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.

:-) Sounds fun, doesn't it? Keeping the message passing between the
edit box and the build box lightweight enough to maintain full
interactivity is the other big challenge, but once working I suspect
it would be a very useful tool. I can't see a way to do it without a
dedicated message server, but that's not necessarily a problem.

> 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!

That must've been fun! An assembler is much easier to do, since
scoping isn't really a problem, just changing label references
(forwards) and branch labels is enough to get something useful
working.

Of course, adding macros to the mix will make it a lot more
complicated ;-)

> 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.  ;-)

This is why I still love the Apple II. Even with 1mb of RAM and 4Mhz
of speed in my IIe, it does not permit me to 'cheat' ;-)

> >> 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.

You'd probably need to decompose large read/write calls at the server
end into smaller requests to maintain a degree (illusionary)
concurrency, and use the message server to 'proxy' interaction
requests. Perhaps with locally buffered writes handled by an interrupt
handler you could maintain a degree of performance but it's one hell
of a complex project.

Matt