On Mar 6, 5:59=A0pm, "Michael J. Mahon"  wrote:

> > The performance difference is due to the reduction in the number of
> > 'native' method calls, which avoid the quite considerable overhead of
> > (de)marshalling and synchronisation (Java only allows a native method
> > to be called from one thread at a time).
>
> > All it shows is that since the majority of the graphics "heavy
> > lifting" is done by a third party API (much of which exists on a GPU
> > these days) you can write your "game logic" in Java
without adding
> > considerable overhead.
>
> > Carmack made a similar assertion a few years back after completing
> > Doom III, and claimed that id's next engine would be written in Java
> > instead of C
>
> This is very similar to writing the fiddly interactive part of an app in
> Applesoft and calling simple M/L subroutines to do most of the heavy
> lifting--a time-tested method of getting the best of both worlds.
>
> As long as most of the time is spent in efficient code, the sparsely
> executed "outer" code can be written in an interpretive language with
> little overall performance penalty and often a saving in space and
> development time.
>
> I do it all the time. =A0;-)

Indeed! Where it tends to differ is that such an example is now a
fringe case, but yet the "performance meme" persists. In today's
"Applesofts" all the common calls to ML are already covered, and the
performance is high enough that you seldom need to revert to lower
level code.

In many ways, insisting on a C/C++ implementation of something today
makes about as much sense as insisting on a pure ML solution in the
Apple II era, when an Applesoft solution would have easily met
expectations.

Matt
--- SBBSecho 2.12-Win32