[gambit-list] good language for real time application?

Marc Feeley feeley at iro.umontreal.ca
Wed Feb 7 15:12:21 EST 2007


On 7-Feb-07, at 1:54 PM, Patrick D. Logan wrote:

> Vincent wrote ..
>
>> I think it would be possible to write it using
>> statically allocated data structures.  Since the boot
>> CD would use the computer as a single purpose machine,
>> I could just take all the memory available and manage
>> it myself rather than using the OS to allocate or
>> deallocate.
>
> Yes, "real-time" generally means "perform within some predictable  
> limits" for time, space, whatever. I am aware of a few real-time  
> systems built with commercial Smalltalk implementations that do  
> essentially pre-allocation of pools of things and put other kinds  
> of controls on the dynamic nature of things.
>
> Erlang is another example. So it comes down to the kinds of limits  
> you have and can you put enough control over things that may blow  
> past those limits.

Here's a simple test I ran to give a rough idea of the GC costs.   
This is on a 2GHz MacBook Pro.  The program (see attachment)  
allocates 1 Mbyte of live data, and then runs a long loop where it  
only allocates garbage.  I ran it with a 200 Mbyte heap.  This models  
the situation of your router, which keeps its live data roughly  
constant and you can use all of the PC's RAM for your program.

% gsc rtgc-test.scm
% gsi -:m200000 rtgc-test
(time (test 1000000))
     1669 ms real time
     1667 ms cpu time (1373 user, 294 system)
     9 collections accounting for 40 ms real time (39 user, 2 system)
     2002887600 bytes allocated
     no minor faults
     no major faults

The average GC pause is 4 milliseconds, and GC time represents 2.4%  
of the total run time (i.e. there is about 160 milliseconds of non-GC  
work between each 4 millisecond GC pause).  Note that this program  
allocates garbage like crazy... real applications usually allocate  
less fast, so there is even more time to do useful work between the  
GC pauses.  My guess is that the 4 millisecond pauses are  
sufficiently short and spread out that they will not affect response  
time very much.  The rule of thumb I have used in the past for soft  
real-time telecom systems is that pauses below 10 milliseconds are  
not problematic.  10 milliseconds would correspond to about 2.5  
Mbytes of live data.  Of course you will have to determine the amount  
of live data in your application and the real-time requirements to  
see if this analysis makes sense.

I would think there are other pauses to worry about if you are  
running your application on a standard operating system (background  
processes, blocking disk I/O, etc).  For a router, the ideal would be  
to run Gambit on the bare metal.  This is actually not too hard (see  
the Nintendo DS port of Gambit).  Now *that* is a neat project!

Marc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rtgc-test.scm
Type: application/octet-stream
Size: 843 bytes
Desc: not available
URL: <http://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20070207/6621cb41/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20070207/6621cb41/attachment.sig>


More information about the Gambit-list mailing list