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

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

mdj wrote:

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.


Right--in any case, it's *another* wave, not "this one", and probably
not for any current programmers.

The "neverending wave" is the parallel wave.  It's neverending because
there is no ultimate limit to the "order" of parallel hardware, and also
because we are going to take a very long time to learn to exploit it.
;-)


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.


I couldn't agree more--the problem we have now is that the "semantic
gap" between languages and machines is not *nearly* wide enough!  ;-)


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)


Yep--that's why the most successful approaches will be dynamically
adaptive.

-michael

NadaPong: Network game demo for Apple II computers!
Home page:  http://members.aol.com/MJMahon/

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