Re: A 21st Century Apple II?

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

On Mar 6, 7:11 am, "Michael J. Mahon" <mjma...@aol.com> wrote:
> apple2fr...@gmail.com wrote:
> > On Mar 5, 3:18 pm, mdj <mdj....@gmail.com> wrote:
> >> On Mar 5, 4:07 pm, apple2fr...@gmail.com wrote:
> >> The reduction in code complexity by using automatic collection however
> >> is a huge benefit to productivity. Consider also that an piece of code
> >> doing it's own collection manually will run more slowly than code that
> >> doesn't, and delegates it to another process that runs in parallel.
>
> > There are pros & cons to both ways of doing it.  Since Java doesn't
> > specify exactly when garbage collection may occur, this can cause
> > execution delays at inconvenient times -- something easily programmed
> > around in C++.  Also, as I mentioned earlier, the C++ Boost library
> > contains a robust garbage collector if that is your thing.
>
> Does Java at least have a way to signal that "now would be a convenient
> time to garbage collect"?  That would go a long way toward eliminating
> inconvenient pauses.

The method call System.gc() has served to hint the collector to run
now since the original specification. However, since the 1.4 series
VM's (going back about 7 years now) you've been able to select from a
variety of different collector "strategies" depending on your specific
needs, and for some strategies the hint is meaningless.

The default collector has for quite some time now used a concurrent
strategy, meaning that on an SMP system you pay no *serial* overhead
for the collector at all. I would suspect that a slight overhead is
incurred in the allocator for the privilege of non-blocking alloc/
release, but can't confirm that.

> >> Also consider the advantages of being able to make optimisation
> >> decisions at runtime vs. compile time. Something your compiler decided
> >> to inline might run beautifully on your machine, but cache-thrash
> >> really badly on your customers smaller system.
>
> > This is true in theory; however in practice I have yet to experience
> > any Java program running more quickly (or with less memory) than an
> > equivalent C++ program on any platform.
>
> This kind of evaluation is one that needs to be done, just to provide
> some objective accountability for the design decision.
>
> I have created lots of examples where dynamic optimization can produce
> a considerable advantage.  I know of two actual experiments in which
> a machine re-wrote its own object code dynamically based on timer-sample
> profile data, and achieved a net improvement of several percent even
> *including* the additional overhead of profiling, analysis, and code
> re-generation!  These were very simple optimizers with tiny "toolkits"
> of patterns.
>
> Of course, the longer the program ran, the less the contribution of the
> overhead and the greater the net improvement.

I'm a big fan of this approach to code optimisation. I think it's not
well understood just how much of an advantage this can be.

Matt