Re: gc notes available

[ttn@mingle.glug.org]

Mikael Djurfeldt writes:

 > Klaus Schilling <Klaus.Schilling@home.ivm.de> writes:
 > 
 > > 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?  ;-)
 > 
 > 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?
 > 
 > 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.
 > 
 > 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?
 > 
 > 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.

I'm w/ the speed-freak here.  Nothing but a double-Jolt is refreshing.

The first jolt is getting simulations to work.  The second one is to put
spiffy graphics and other mindbending aesthetic feedback.  If Guile's
Scheme can't do screensavers, it must be given some fast path to do so.

I like the idea of exposed gc config bits.  An application should be
able to declare: ok I'm feeling confident, and have the fast path
invoked.  In fact, if someone clueful can tell me what bits are good to
expose (my guess would start w/ `scm_block_gc'), I can do some munging.
Currently, there exists `gc-stats', but that's just a getter.  Proposed
bindings, initially not multithreaded:

function: gc-conf-bit bit
	The value of gc config BIT, or unspecified if unknown BIT.

procedure: gc-conf-bit-set! bit val
	Set gc config BIT to VAL if BIT known.  Unspecifed value.

(From these two simple ones, anything else can be introduced later.)

This exposes (to me at least) the argument: should applications really
need to twiddle gc config bits?  And the answer is yes.  If an app needs
performance (to get back to mdj's question), mechanisms to manipulate
its environment towards that end should be part of the environment.

So, no, a language has no performance requirement, but the language
implementation surely has.  As implementation moves more towards
simulation (aka emulation aka interpretation), this will apply more to
software than before (but always has for hardware).  Anything's design
is fundamentally different from its implementation, but maybe not for
long.

thi