Re: P-Source: A Guide to the Apple Pascal System

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

On Nov 28, 6:42 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:
> mdj wrote:
> > On Nov 27, 3:38 pm, David Schmenk <dschm...@YUCH.gmail.com> wrote:
>
> >>One thing I've found out during this exercise is that current Java
> >>technology has really segmented itself.  There are all sorts of versions
> >>out there to try and satisfy each market.  A small device that runs Java
> >>has megabytes of memory and a 32 bit processor.  Nano device have ~200K
> >>memory and 16 bit processors.  Many of the small devices and almost all
> >>the nano devices have specialized build procedures that massage the Java
> >>class files into a more palatable native format.  Doesn't that run
> >>counter to the write once, debug everywhere goal?  The standard class
> >>library gets progressively smaller as the device shrinks, too. In the
> >>end, I think its a testament what the p-system was able to pull off with
> >>the technology available.
>
> > Yeah, the only real advantage is having one source language across
> > virtually every device, but you're right, the 'tiny' implementations
> > are pretty light on for class libraries.
>
> > Having said that, it's interesting to note that what was a 'tiny'
> > device a few short years ago (eg. a Cell Phone) can, thanks to
> > technology progression, now run the entire J2SE implementation, so the
> > benefits become greater as technology improves and today's embedded
> > device matches yesterdays desktop for computing power.
>
> Riding the Moore's "Law" wave has become such a way of life in
> the software business that it's hard to believe that anyone ever
> struggled to produce finely crafted code.  ;-)
>
> And now it will be hard to adapt to the new reality:
>
> We can no longer expect that the processing capacity of our code
> will be sped up by a relentless increase in thread execution speed.
> Now that the uniprocessor wave is over, we need to be planning for
> larger, and variable, numbers of processors running our (still very
> serialized) code--like, more than 50...

While the current wave may be over, I think there's probably another
one beyond photo lithography based approaches but that's potentially
decades away.

> Unfortunately, "threads" as currently conceptualized, are a relatively
> poor abstraction for expressing the fractal parallelism that is needed.

Agreed. I'm relatively confident (in fact, have long predicted) a
pivot in the software unwieldiness trend. Far more sophisticated tool
chains down the track, with the thread execution speed cap becoming
the driver. I fit in to the "Languages aren't abstract enough" camp,
and not just for parallel computing but imperative programming
languages in general; there is still a very big gap between the 'minds
eye' view of a piece of code and its physical representation.

Once we're firmly into the parallel era another personal axiom becomes
pertinent: "For any program x, there will be a workload y in which x
performs (relatively) poorly"

Unless... :-) (You get the idea)

Matt