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.
-Patrick
Afficher les réponses par date
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
A simple example will show the problem I'm running into - is there any workaround?
rafimac:/scheme raffaelc$ cat test.scm (c-declare #<<c-declare-end double test(double afloat, double anotherfloat) { return (afloat + anotherfloat); } c-declare-end )
(define test (c-lambda (double double) double "test"))rafimac:/scheme raffaelc$ rafimac:/scheme raffaelc$ gsc Gambit Version 4.0 beta 20
(compile-file "/scheme/test.scm")
#t
(load "/scheme/test")
"/scheme/test.o1"
(test 2.0 2.0)
4.
(exit)
rafimac:/scheme raffaelc$ gsc Gambit Version 4.0 beta 20
(load "~~/syntax-case")
"/usr/local/Gambit-C/4.0b20/syntax-case.scm"
(compile-file "/scheme/test.scm")
*** ERROR IN "/scheme/test.scm"@1.1 -- Argument to 'c-declare' must be a string #f
regards,
Ralph
Raffael Cavallaro, Ph.D. raffaelcavallaro@mac.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 7-Feb-07, at 7:46 PM, Raffael Cavallaro wrote:
A simple example will show the problem I'm running into - is there any workaround?
rafimac:/scheme raffaelc$ cat test.scm (c-declare #<<c-declare-end double test(double afloat, double anotherfloat) { return (afloat + anotherfloat); } c-declare-end )
(define test (c-lambda (double double) double "test"))rafimac:/scheme raffaelc$ rafimac:/scheme raffaelc$ gsc Gambit Version 4.0 beta 20
(compile-file "/scheme/test.scm")
#t
(load "/scheme/test")
"/scheme/test.o1"
(test 2.0 2.0)
(exit)
rafimac:/scheme raffaelc$ gsc Gambit Version 4.0 beta 20
(load "~~/syntax-case")
"/usr/local/Gambit-C/4.0b20/syntax-case.scm"
(compile-file "/scheme/test.scm")
*** ERROR IN "/scheme/test.scm"@1.1 -- Argument to 'c-declare' must be a string #f
That's a problem with the syntax-case expander, it has nothing to do with the #<< syntax. Unfortunately the syntax-case expander turns things like
(foo "abc")
into
(foo '"abc")
which is incorrect when foo is c-declare, or include, etc. It's probably easy to fix for the implementors of syntax-case (Dybvig et al), but I shudder at the thought of figuring out which of the over 40 usages of 'quote in syntax-case.scm has to be made conditional on the object being quoted (the quote should be dropped for strings, numbers, booleans, and characters).
Marc
--- Marc Feeley feeley@iro.umontreal.ca wrote:
Here's a simple test I ran to give a rough idea of the GC costs.
....
The average GC pause is 4 milliseconds, and GC time represents 2.4% of the total run time ....
Thank you for the sample code. That's a good way to get a rough idea. Thinking further about the requirements of a global P2P network, I think the response times for each node have to be measured in microseconds rather than milliseconds. In telecom networks, packets can travel over long distance fiber links, with fewer nodes to introduce delay. In a global P2P network, packets would have to travel through maybe 100 times more nodes, with shorter distances between nodes, and each node introducing delay. If a packet has to hop through 1000 nodes, the total delay will be the per node delay times 1000. If each node takes 200 microseconds to recieve a packet, and 200 microseconds to send a packet, that's about half a second latency right there.
Has anybody on this list ever used BitC or Coyotos? I just read about those this morning. I'm thinking maybe I should go in that direction. Here's a page describing BitC - it looks like a very interesting language.
http://www.coyotos.org/docs/bitc/spec.html
Vincent
____________________________________________________________________________________ Get your own web address. Have a HUGE year through Yahoo! Small Business. http://smallbusiness.yahoo.com/domains/?p=BESTDEAL
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 8-Feb-07, at 1:07 PM, Vincent wrote:
--- Marc Feeley feeley@iro.umontreal.ca wrote:
Here's a simple test I ran to give a rough idea of the GC costs.
....
The average GC pause is 4 milliseconds, and GC time represents 2.4% of the total run time ....
Thank you for the sample code. That's a good way to get a rough idea. Thinking further about the requirements of a global P2P network, I think the response times for each node have to be measured in microseconds rather than milliseconds. In telecom networks, packets can travel over long distance fiber links, with fewer nodes to introduce delay. In a global P2P network, packets would have to travel through maybe 100 times more nodes, with shorter distances between nodes, and each node introducing delay. If a packet has to hop through 1000 nodes, the total delay will be the per node delay times 1000. If each node takes 200 microseconds to recieve a packet, and 200 microseconds to send a packet, that's about half a second latency right there.
But 4 milliseconds is the GC pause time and the GC is called infrequently. So very few of the hops in your 1000 node chain will require an extra 4 milliseconds from GC. On such a long chain, the average impact on the latency will be very close to an overhead of 2.4% (so if you assume it takes 400 microseconds worth of pure CPU work to handle a packet, it will take 409.6 milliseconds instead of 400 milleseconds of total latency for 1000 hops). Such a small overhead will be negligible compared to the quality of the generated code, the memory management overhead, the I/O overhead, the process scheduling overhead, etc.
Marc