[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Nov 14 12:50:57 1992 
Subject:Re: Re: help [Real time and Pop-11] 
From:Aaron Sloman 
Volume-ID:921114.14 

sfk@otter.hpl.hp.com (Steve Knight) writes:

> Date: 13 Nov 92 17:32:04 GMT
> Organization: Hewlett-Packard Laboratories, Bristol, UK.

> This, I hope, gives a picture of Pop as a (family of) high-level language
> that is suitable for complex programming tasks.  Its implementation
> technology is very similiar to modern-day Lisp systems.  No current
> implementations are suitable for "real-time" programming, by which
> I mean applications that are critically sensitive to unpredictable
> delays, since the demands of garbage collection and virtual memory are
> difficult to reconcile with real-time work.

Actually Steve is not quite right. If you think in terms of
micro-second and millisecond response he is. But if you are
concerned with real time control of relatively slow moving systems
where responses within a few seconds or a few minutes are acceptable
then Pop-11 can be at least as good as or better than a human
operator, as was shown by the RESCU project (Real Time Expert
Systems Club) during the Alvey Programme in the late 80s. The
system, written in Pop-11, and running under VMS on a VAX 730 (not
the world's fastest machine even in those days), responded fast
enough to control a detergent manufacturing process.

A knowledgable programmer can (for certain sorts of programs)
eliminate garbage collections or keep the time requirements quite
low because the Poplog garbage collector is VERY fast. E.g. I am
currently typing in an editor that is integrated with Poplog and
includes all my email reading and writing utilities, news reading
and posting utilities, and much more besides (in a saved image). The
total process size as shown by ps -ux on a SS 10/30

    USER      PID  %CPU %MEM SZ  RSS  TT STAT START  TIME COMMAND
    axs      28005  0.0 6.7 2416 1896 p1 S    07:21   0:26 pop11 +bved.psv gtm

seems to be about 2.5Mbytes. If I stop editing and run a little
program that repeatedly builds a lot of lists and throws them away
I *predictably* get garbage collection times of under 0.15 seconds,
e.g. 0.12 secs and 0.10 secs in this example:

: repeat 1000 times [% for x to 99 do [%x%] endfor %] -> endrepeat;
;;; GC-auto(C) 0.12  MEM: u 104465 + f 284643 + s 12 = 389120
;;; GC-auto(C) 0.10  MEM: u 104996 + f 284092 + s 32 = 389120

(The numbers after MEM refer to 32 bit words in volatile memory. So
I have approximately 417K bytes of stuff in the heap that's fixed,
and approximately 1136K bytes turning over, with a total heap size
of about 1.5Mbytes.)

Obviously on a slower machine the same garbage collections would
take longer.

It's worth noting that Steve's comments about limitations of Pop-11
for realtime uses apply equally to most Unix systems, which can have
all sorts of things going on that cause unpredictable delays while a
program is running. I don't think Pop-11's unpredictability adds
significantly to this in the hands of a knowledgeable programmer.
Of course, it may not run as fast as a C program doing the same
thing, but it will be much easier to develop and maintain than a C
program.

> ...However, Pop is suitable
> for general-purpose programming tasks since the typical run-time system
> is not excessive by the standards of today's technology.  For example,
> the richest and most complex implementation (POP-11) has a run-time
> executable of approximately 500Kb.

That's a bit out of date: The latest distributed version of Pop-11
(in Poplog V14.1) with hooks for X, and including the incremental
compiler, the integrated editor VED (similar in philosophy and
programmability to Emacs), the core of prolog, etc. is a nearly four
times that size on a typical RISC machine. E.g. on a SPARC

    size $popsys/basepop11
    text    data    bss     dec     hex
    1556480 172032  245800  1974312 1e2028

and slightly smaller on a CISC amchine, e.g. an HP M68040 system

    size $popsys/basepop11
    1235336 + 134264 + 292980 = 1662580

It is possible to build an executable that's well below a megabyte,
but nowadays people mostly prefer to have the extra facilities. Of
course, on a machine with virtual memory, a user who employs only a
subset of the facilities in Pop-11 will actually not need to take
up much space in memory. For reasons that I don't understand Pop-11
seems to require far less memory than most commercial lisp systems
even when you add the Poplog Common Lisp, e.g. starting up Poplog
Common lisp:

    % pop11 +clisp

    Sussex POPLOG (Version 14.1 Thu Jun 11 15:30:52 BST 1992)
    Common Lisp (Version 1.4)

    Setlisp
    == ^Z
    Stopped

    % ps -ux
    USER       PID %CPU %MEM   SZ  RSS TT STAT START  TIME COMMAND
    axs      29056  0.0  5.9 2276 1660 p1 T    12:24   0:00 clisp

I.e. just over 2MB for Poplog Common Lisp, Plus Pop-11, Plus VED.

Adding either Prolog or ML to Pop-11 gives slightly smaller sizes
than lisp:

    % ps -ux
    USER       PID %CPU %MEM   SZ  RSS TT STAT START  TIME COMMAND
    axs      29113  0.0  5.4 2100 1524 p1 T    12:38   0:00 pop11 +pml
    axs      29115  0.0  5.1 1916 1436 p1 T    12:38   0:00 pop11 +prolog

Compare your favourite commercial Common Lisp on a Sparc.

    % lisp
    ;;; Sun Common Lisp, Development Environment 4.0.1, 6 July 1990
    ;;; Sun-4 Version for SunOS 4.0.x and sunOS 4.1
        .....
    > ^Z
    Stopped
    % ps -ux
    USER       PID %CPU %MEM    SZ  RSS TT STAT START  TIME COMMAND
    axs      29126  0.0 31.7 21768 8960 p1 T    12:41   0:01 lisp

I.e. 21 Mbytes ???

    % size /bham/bin/lisp
    text    data    bss     dec             hex
    7593984 5963776 0       13557760        cee000

Of course, memory prices are falling, but nevertheless....
Aaron
-- 
Aaron Sloman, School of Computer Science,
The University of Birmingham, B15 2TT, England
EMAIL   A.Sloman@cs.bham.ac.uk  OR A.Sloman@bham.ac.uk
Phone: +44-(0)21-414-3711       Fax:   +44-(0)21-414-4281