Does anyone have info on using lisp in a real-time environment? It's very
convenient for writing code, but are there good ways to keep memory usage
under tight control and to make sure that response times (i.e. not hanging on
GC) reasonable?
This isn't intended to be flamebait. I'd love to use lisp for some of my
work, but the need to port the code to real-time environments hampers this.
--
Jerry Quinn Tel: (514) 761-8737
······@nortel.ca Fax: (514) 761-8505
Speech Recognition Research
See http://www.cogent.ca/SLisp.htm .
Also note that Gensym Corp built the original version of its G2 Expert System
in Lisp. As I understand (someone please correct me if I get this wrong), G2
was designed as a development framework for real-time expert systems. The
original implementation of G2 in Lisp was very carefully written to use
efficient data structures, and succeeded in real-time environments. G2 was
later rewritten in C due to market pressures.
Perhaps someone familiar with the original G2 project could provide some
additional details...
Jerry Quinn wrote:
>
> Does anyone have info on using lisp in a real-time environment? It's very
> convenient for writing code, but are there good ways to keep memory usage
> under tight control and to make sure that response times (i.e. not hanging on
> GC) reasonable?
>
> This isn't intended to be flamebait. I'd love to use lisp for some of my
> work, but the need to port the code to real-time environments hampers this.
>
> --
> Jerry Quinn Tel: (514) 761-8737
> ······@nortel.ca Fax: (514) 761-8505
> Speech Recognition Research
In article <···············@ecars147.nortel.ca> Jerry Quinn
<······@ecars147.nortel.ca> writes:
>
> Does anyone have info on using lisp in a real-time environment? It's very
> convenient for writing code, but are there good ways to keep memory usage
> under tight control and to make sure that response times (i.e. not hanging on
> GC) reasonable?
>
> This isn't intended to be flamebait. I'd love to use lisp for some of my
> work, but the need to port the code to real-time environments hampers this.
>
>
Much of the world has discovered, or is painfully discovering, that to write
C programs that do the same kinds of things that Lisp programs do well, you
have to do the same kinds of things *in C* such as lists, memory management,
symbolic and expression interpretation, dynamic typing, dynamic classes,
meta classes etc... Hence lower level programming languages are not good
substitutes for Lisp. They are just missing a lot of the capabilities that
Lisp has. The great development advantages that Lisp has over lower level
programming languages is a separate issue.
So based on this, there is apparently no escaping these kinds of problems
since you will encounter them, even if you code in assembly language. It is
funny that some people actually believe that if you program in C these
problems will somehow not ultimately exist. So, to answer your question,
there are some Lisp species that more efficiently handle these kinds of
problems than others, but typically the world uses a different approach for
real time problems.
It all depends on what you mean by a real time environment. For example
there are now Lisp web servers that people use every day and do not even
realize that they are talking to Lisp programs in real time.
If you are talking about a stringent real-time environment such as a robot
controller or machine tool then an intelligent server or intelligent agent
approach is typically used. For example
-----------------------
| |
| Intelligent | messages ---------------- **
| Agent | ---------> | Servo & |
| | | Sensor | <---> Real
| Lisp environment | <--------- | Controller | World
| | messages ----------------
----------------------- (in C, assembly etc.)
The messages are sent over a port as in a client/server arrangement. There
are many kinds of query languages defined for communicating knowledge from
the responsive but dumb controller to the intelligent agent.
The dependency on real time responsiveness is broken by the "brain" to
controller barrier. Each agent queues messages from the other for
processing. There are various kinds of queuing technologies depending on
the application. The controller will always have "safety loops" to respond
to emergencies while waiting for messages from the Intelligent Agent. By
design the controller is usually quite small with tight loops and hands off
higher level decisions to the intelligent agent.
It would be nice if there was an "Efficient Lisp" so that it could be used
in the ** box on the right, and as far as I know, maybe there is. Basically
just having a Lisp syntax that translates into C semantics or even more Von
Neumann machine specific semantics would be a good start. But, not to put
down controllers, the more interesting stuff these days is happening in the
box to the left and we have "good enough" languages and packages for the box
on the right.
--
William P. Vrotney - ·······@netcom.com
In article <·················@netcom.com>, ·······@netcom.com (William Paul Vrotney) writes:
|> meta classes etc... Hence lower level programming languages are not good
|> substitutes for Lisp. They are just missing a lot of the capabilities that
|> Lisp has. The great development advantages that Lisp has over lower level
|> programming languages is a separate issue.
It is for this reason we developed Erlang. We wished to use dynmically typed
functional languages for distributed applications with a lot of concurrency.
|> If you are talking about a stringent real-time environment such as a robot
|> controller or machine tool then an intelligent server or intelligent agent
|> approach is typically used. For example
|>
|> -----------------------
|> | |
|> | Intelligent | messages ---------------- **
|> | Agent | ---------> | Servo & |
|> | | | Sensor | <---> Real
|> | Lisp environment | <--------- | Controller | World
|> | | messages ----------------
|> ----------------------- (in C, assembly etc.)
This is exactly the kind of architecture we use, except our picture is more
---------------------
|Processor |
|Intelligent Control|---+ --------------------------
|System in Erlang | |-----------------|processor for HW control|
--------------------- | --------------------------
|
--------------------- | --------------------------
|Processor | |-----------------|processor for HW control|
|Intelligent Control|---+ --------------------------
|System in Erlang | |
--------------------- | --------------------------
. -----------------|processor for HW control|
. | --------------------------
.
--------------------- | --------------------------
|Processor | |-----------------|processor for HW control|
|Intelligent Control|---+ --------------------------
|System in Erlang |
---------------------
I.e. we have a few central intelligent processors and many small processors
which control the hardware and where the hard real time control is done.
Between processors we use various networks (ATM, Ethernet or whatever).
Communication is by message passing.
Erlang is a dynamically typed functional language which supports
threads and distributed processing. We also have exception mechanisms
which allows threads to supervise each other in a distributed environment.
To prevent large delays for GC, each thread is individually GC'ed.
|> It would be nice if there was an "Efficient Lisp" so that it could be used
|> in the ** box on the right, and as far as I know, maybe there is.
I can't give you an 'Efficient Lisp', but I can give you a language
very similar to Lisp. Moreover a mature language which has been used
by us (Ericsson) to build many very significant industrial products
containing several hundreds of thousands of lines of code.
There is a free version available if you would like to try it out,
look in http://www.erlang.se
/Mike Williams
On 19 Mar 1998 08:47:36 GMT, ····@erix.ericsson.se (Mike Williams) wrote:
> |> It would be nice if there was an "Efficient Lisp" so that it could be used
> |> in the ** box on the right, and as far as I know, maybe there is.
>
> I can't give you an 'Efficient Lisp', but I can give you a language
> very similar to Lisp. Moreover a mature language which has been used
> by us (Ericsson) to build many very significant industrial products
> containing several hundreds of thousands of lines of code.
Harlequin has a real time variant of LispWorks called "Hercules", used by
AT&T.
__Jason
·····@harlequin.com (Jason Trenouth) wrote:
>Harlequin has a real time variant of LispWorks called "Hercules", used by
>AT&T.
BTW, the systems-and-technology portion of AT&T has split off from the
parent company, and is now known as Lucent Technologies.
Lawrence G. Mayka
·······@sprynet.com
Take a look at Gensym's stuff: http://www.gensym.com
-- David Kuznick ········@bdsw.com or ········@world.std.com
"I remember cities and I remember rain, like the sound of your voice,
falling. These memories and more remain.... So where do we begin and
what else can we say? When the lines are all drawn, what should we do
today?" A Pleasant Shade of Gray (Part XII) - FATES WARNING
I will likely use a Lisp dialect as the language to implement
the engine control and data logging in my car(s), i.e.
it will control my (homebrewed) electronic fuel injection and ignition.
This is hard real time, if the program can't keep up, the engine can
be destroyed. Obviously, it can't stop to GC.
It clearly will also not be Common Lisp, the entire system must
fit into at most 512K. It'd probably be more like "L",
robot controller Lisp dialect from Rodney Brooks.
Hey, should I try to get government funding for my hobby(s)? ;)
Gensym's G2 real-time system also did not use GC.
They used a CL subset, and required a few special
CL implementation-dependent support macros to avoid
gc-causing consing of floating-point and bignums,
such as (with-temp-floating-point ...), that allocated any numbers
in an area that is reset when the macro exits.
I understand their code is still developing using Common Lisp,
in fact, I think they still use TI Explorer Lisp Machines.
They translate the code into C code for delivery.
-Kelly Murray ···@franz.com
In article <············@news2.franz.com>, Kelly Murray <···@franz.com> wrote:
>I understand their code is still developing using Common Lisp,
>in fact, I think they still use TI Explorer Lisp Machines.
Do I dare admit that I still use a TI Explorer as my main workstation?
(Yep, even for newsgroup reading...)
-- Dan Corkill
Date: 23 Mar 98 21:59:56 GMT
From: ····@cs.umass.edu (dan corkill)
Do I dare admit that I still use a TI Explorer as my main workstation?
(Yep, even for newsgroup reading...)
Comes in handy during those Massachusetts winters.
(I used one as my primary mail machine, till we moved in January to a
building with insufficient air-conditioning. It still runs, just not
very often.)
Paul Fuqua
Texas Instruments, Dallas, Texas ··@hc.ti.com
The September 1991 issue of Communications of ACM contains among other
Lisp-related items the article "Real-time programming in Common Lisp".
ACM Computing Reviews comments on the papers:
"LISP may be used for real-time applications through sophisticated
programming techniques to avoid its main advantages: dynamic typing,
dynamic memory storage, and garbage collection."
Bear in mind that this is seven years ago, and the world has changed
quite a bit after that.
--
pertti
In article <···············@ecars147.nortel.ca>, Jerry Quinn
<······@ecars147.nortel.ca> wrote:
> Does anyone have info on using lisp in a real-time environment?
- Maybe ISR's L system is interesting. It's CL for real-time
embedded systems: http://www.isr.com/tech/default.html .
- RScheme claims to have a realtime GC: http://www.rscheme.org/ .
--
http://www.lavielle.com/~joswig/