This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
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