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