Re: Scripting

[Steve Baker <sjbaker1@airmail.net>]

Katie Lauren Lucas wrote:
> 
> Quoting Jorrit Tyberghein <Jorrit.Tyberghein@uz.kuleuven.ac.be>:
> 
> > I also don't agree with this completely... With Java there is now
> > technology
> > that does compilation at runtime (JIT and HotSpot technologies). This
> > allows
> > 'interpreted' languages to become FASTER than C++ in theory (see the
> > word 'in theory') because at run time you have information about the
> > program
> > that at compile time simply isn't present. For example, HotSpot
> > optimizes
> > code at run time if it sees that code is used a lot. There is still a
> > lot of research
> > going on in these areas but in theory the potential is there so that
> > interpreted
> > languages could (in future) run faster than compiled languages just
> > because
> > a compiler doesn't have sufficient information to optimize without the
> > program running.
> 
> I've always felt this claim a little dubious: even assuming your optimiser
> takes near-zero time, time is consumed taken detecting the "hotspots", and I
> don't quite see how any code optimisation could be produced at run-time that
> couldn't be produced at execution time, apart from (possibly) unrolling loops
> based on run-time data...

...yes - and after all, a non-realtime "traditional" compiler can just optimise
*ALL* of the code that well - regardless of whether it's used frequently or not.

The reason HotSpot is a good idea for an interpreter is that for infrequently
executed code, you can't optimise the code as well as you'd like to because
it takes longer than the time you'd save.  Hence, recognising the hot spots
allows you to come *closer* to the performance of a conventional compiler.

I think this is a ridiculous claim - and if it were remotely likely to be
true then that's how C++ compilers would work.  You'd compile the program
offline - optimise it the best you possibly could with static knowledge of
the nature of the program - then keep a copy of the code and re-optimise
it based on this nebulous "additional information" that somehow becomes
available.

But again - like garbage collection - this is a dubious thing for games
and other 'hard realtime' applications.  There you are, with carefully
written code that's managing to make it around your render loop in 16ms,
then the stoopid interpreter says "Woah! You've been around that loop
more than 1000 times - I'd better optimise it!"...it then goes away for (say)
50ms to beat the heck out of the code - and you just dropped three frames!
Then the player walks into another room - all that optimised code is never
run again and 1000 iterations later **BANG** another glitch in the rendering.

Gee - thanks!

It's not about programs that run fast enough *ON* *AVERAGE* - it's about
having reliable, predictable timing that's good enough *EVERY* *FRAME*.

Actually, in most things I write, I have to avoid memory allocation and
deallocation wherever possible because even without garbage collection, the
underlying 'malloc' and 'free' implementations are not very uniform in
execution times...nowhere near as irregular as a garbage collector or
on-the-fly compiler would be - but still variable enough to be problematic.

You see there is a LOT to the art of realtime programming (of which game
programming is a subset) that is quite different from general programming
and applying the principles of general programming to the problems that
this mailing list addresses is **WRONG**.

I don't care if Language-A is 10x faster than Language-B if 'A' pauses
for a half second every couple of minutes, it's unusable - period.
However, we aren't even talking about that - we are comparing a language
that's 10x SLOWER than the alternatives that ALSO 'goes away' for a while
every so often...that's a no-brainer for me.

> {Actually, having thuoght about it, unless you can actually solve the halting
> problem you CAN'T do things like unroll loops knowing they're always called
> with the same count - you only know that that's the case at program
> termination. (You could /guess/ but that's not the same). If you can solve the
> halting problem hot-spot and traditional optimisers will give you the same
> results.}

At best.

----------------------------- Steve Baker -------------------------------
Mail : <sjbaker1@airmail.net>   WorkMail: <sjbaker@link.com>
URLs : http://www.sjbaker.org
       http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
       http://prettypoly.sf.net http://freeglut.sf.net
       http://toobular.sf.net   http://lodestone.sf.net