Re: gc notes available

[Greg Harvey <Greg.Harvey@thezone.net>]

Mikael Djurfeldt <mdj@nada.kth.se> writes:

> Klaus Schilling <Klaus.Schilling@home.ivm.de> writes:
> 
> > My game is downright discrete in time and space, so the conservative gc 
> > behaves quite well for this special game. (just take a cup of camilla tea in 
> > the gc breaks)
> > 
> > What would be typical apps, games or serious, where both the expressive power 
> > of scheme scripting and the realtime animated pixel stuff are actually needed?
> 
> I'm surprised that not more people are interested in realtime
> performance.  I thought the main intended use for Guile was as an
> application extension language.  Doesn't it occur often in large
> classes of applications that realtime performance is important?  Isn't
> the expressive power of scheme still a good thing in an extension
> language?  (Could it be that folks interested in Guile is a bunch of
> refugees that find the real world a scary place?  ;-)

No, eval.c is a scary place ;)  
 
> Here's an example:
> 
> 
> I'm working on a neuron simulator.  I want to be able to do data
> presentation which change over time, for example a schematic graph
> over a dendritic tree where the colors indicate membrane potential of
> the compartment at a given moment of time.  I want to be able to
> follow the waves of activity over the compartments of the cell in
> (slowed down) real time.
> 
> This seems to be a suitable task for a canvas-like widget (the
> compartments aren't that many).
> 
> 
> Should I really need to do all dynamic GUI stuff in C code?

Definately not. But, is it going to be generating that much garbage
that the gc will be invoked so many times as to slow the thing down
noticably?  This is not just an issue with guile, but pretty much
every available implementation of a lisp-like language with gc. As an
example, from the allegro lisp manual: "... but scavenges are supposed
to be so fast that human(sic) barely notice them." 


> To me it seems like modern applications often have realtime components
> in their GUI:s.  I'd still be able to do much of this in Scheme.
> 
> Even in "ordinary" GUI:s (remember that GUI:s is a major task for an
> application extension language---look at Tcl/Tk), it is very
> important, ergonomically and psychologically, that the GUI isn't
> sluggish or have irregular response.

This is a desire for very short, unnoticable pauses, and that's the
goal anyway.

> I have a prototype GUI for my simulator and I must confess (remember
> that I'm a person who really loves Guile) that Java-GUI:s feel more
> professional due to these dynamic effects.
> 
> May I ask: How important is *performance* in a scripting language?

Important, but not the most vital bit in most uses. The main benefit
to a scripting language is the programming time it saves. For an
example, the script I use to connect to my isp and keep track of
online time (the way they charge is a bit funky) is written in
perl. It doesn't matter to me whether it takes 5 ms or 5 seconds to
start up, as long as it does the job and lets me know how close I am
to having to pay $1.50 an hour. 

This is not to say that guile should remain as slow as it is. A
compiler (hobbit, bytecode, whatever) would be a major benefit; so
will the new gc, and as a plus, it will provide a well defined
interface to make it a lot easier to use plug in a different gc (gotta
plug the gc every chance I get ;).

> Regardless of if the garbage collector is faster or slower, I'll still
> have to do time critical calculations in C.  The performance of other
> things will of course be influenced.  But this is a difference of
> degree.
> 
> If I don't have realtime performance, there is a class of tasks which
> I can't do at all.

-- 
Greg