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

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

On Nov 28, 6:50 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:

> > JVM's do two classes of optimisation in the JIT stage which have
> > tremendous performance benefits: multi-level inlining and temporary
> > object allocation. Temporary allocation is important since Java at the
> > language level only supports dynamic allocation for objects, but a
> > 'smart' JIT can identify object references that have only single-tier
> > scope and allocate them on the stack instead. I would imagine both of
> > these optimisations would still be very fruitful for the 'hot' path,
> > even on a very small machine. Applying these techniques and *then*
> > doing a native code transform could yield a pretty good improvement,
> > and it's certainly feasible even on a limited machine.
>
> Particularly since both of these optimization steps are a lot like a
> a "transliteration with address substitution".  That's why a budget of
> 100 cycles per generated byte is probably realizable.

Agreed.

> (BTW, I'm a big believer in setting time and space "budgets" for
> functions prior to implementation--so you know when you've gone off
> the deep end.  ;-)

I have similar views - I usually code with the rule that a function
should more-or-less fit on the screen. If it's bigger than that, then
it is probably > 1 functions :-)

I have however been accused of being an indirectionaholic in past, but
the newer runtime systems have shown I can have my cake and eat it too
so I'm not backing down on that one anytime soon :-)

> > I agree completely with this. I do however think there's a class of
> > 'pascal sized' applications that could be written in Java instead, and
> > finding creative solutions to the optimisation problems sounds like a
> > really fun academic exercise. There's certainly room to do far better
> > than the p-machine implementations did!
>
> I would love to see a serious attempt made.  But don't underestimate
> the effort put into optimizing the p-system.  They achieved most of
> their objectives (which many regarded as impossible at the time) and
> only failed to achieve their non-objectives.  ;-)
>
> We've learned a few things since then, but we've forgotten so much.. ;-)

Oh, I doubt it's possible to get more than a few percent improvement
out of the interpreters execution speed. Certainly big chunks of the
OS itself could do with an overhaul, but one of the advantages of
going for the JVM approach would be building it from scratch to run
under ProDOS (and possibly be able to relocate itself into the
Auxiliary Language Card *hint hint*)

I think the really interesting improvements would come from a runtime
profiler/compiler that applied all the the feasible dynamic
optimisations.

Matt