Hi,
We are using CMU (16f+17c), PCL, CLX and GINA (which is built upon
Motif, CLX and CLOS) and we wonder if we did something wrong with our
installation. It feels slow and garbage collections happen very often,
especially with graphical applications.
One of our students also works in another laboratory where they have
Lucid. He says that it's much smoother to use, even with GINA.
One of our problems seems to be garbage collection. It lasts for
several seconds and stops any graphical output and refreshes in
windows, which isn't nice at all with interactive applications.
The Python compiler is supposed to be very good at optimization. What
kind of switches or possibilities are there to further optimize the
quality of the generated code?
Should we look up our programs for specific kinds of (bad/suboptimal)
programming style that might lead to the undesired behavior?
What other variables should be checked or can possibly influence the
speed of the overall system?
We've set
(setq *bytes-consed-between-gcs* 5000000)
Are other GINA users affected? What do they feel?
We are using SunOS4.1.1-3 on Sun IPC, IPX, SparcII and 10-20/30
machines running with 32MB RAM and OpenWindows 3.
Thanks for any hints,
Joerg Hoehle.
······@inf-wiss.uni-konstanz.de
Hello,
I have had the same problem. It seems to me that the garbage collector
of CMUCL is its weakest point.
The CLM/GINA group had a note about one of the 'time' functions
slowing down the system because of consing. (I think it was
'get-universal-time' or one of those - I'd have to unpack the README to
find out).
CMUCL 17c comes with a Motif server which has essentially the same
architecture of CLM/GINA and it does not cons.
Maybe somebody at CMU could quickly tell us what are the main
differences. It would also be interesting to know if anybody has tried
to run GINA on CMUCL 17c without installing CLM.
Happy Lisping
--
Marco Antoniotti
-------------------------------------------------------------------------------
Robotics Lab | room: 1219 - tel. #: (212) 998 3370
Courant Institute NYU | e-mail: ·······@cs.nyu.edu
...e` la semplicita` che e` difficile a farsi.
...it is simplicity that is difficult to make.
Bertholdt Brecht
From: Michael Garland
Subject: Re: making CMU + PCL + CLX + GINA run faster?
Date:
Message-ID: <CLCGuz.Iw6.3@cs.cmu.edu>
In article <·····················@graphics.cs.nyu.edu>,
Marco Antoniotti <·······@graphics.cs.nyu.edu> wrote:
>
>Hello,
>
>Maybe somebody at CMU could quickly tell us what are the main
>differences. It would also be interesting to know if anybody has tried
>to run GINA on CMUCL 17c without installing CLM.
There are two relevant documents included in the release. In the
archive 17c-extra-sunos.tar.Z, you can find:
./doc/motif-internals.doc
./doc/motif-toolkit.doc
Below, I've included a brief summary (excerpted from
motif-internals.doc) of the differences with CLM. Indeed, the CMUCL
Motif interface is very much like CLM in terms of the interface it
provides the client program; in contrast, the interior architecture is
radically different. Unfortunately, there are critical differences
which prohibit the use of an unmodified GINA.
The departures from the CLM interface were generally motivated by one
of two reasons: (1) an attempt to improve the usuability of the
interface and (2) to accomodate improved efficiency. It is my belief
that the CMUCL Motif interface is appreciably faster than CLM, both
because it conses much less and because its network protocol is more
efficient. Having said this I must confess that, being responsible
for building it, my opinions are highly biased.
-Michael Garland
-----------------------------------------------------------------
Summary of differences with CLM --
----------------------------------
- X objects (eg. windows, fonts, pixmaps) are represented as CLX objects
rather than the home-brewed representations of CLM. As a consequence, this
requires that CLX be present in the core. If this were to cause
unacceptable core bloat, a skeletal CLX could be built which only supported
the required functionality.
- Stricter naming conventions are used, in particular for enumerated
types. A value named XmFOO_BAR in C will be called :foo-bar in Lisp,
consistently. Abbreviations such as :form (for :attach-form) are not
allowed since they are often ambiguous. Where CLM abbreviates callback
names (eg. XmNactivateCallback becomes :activate), we do not (eg.
:activate-callback).
- Some differently named functions which can be resolved without undo
hassle.
- Passing of information to callbacks and event handlers. In CLM,
callback handlers are defined as:
(defun handler (widget client-data &rest call-data) .... )
The client-data argument is some arbitrary data which was stashed with the
callback when it was registered by the application. The call-data
represents the call-data information provided by Motif to the callback
handler. Each data item of the callback information is passed as a
separate argument. In our world, callback handlers are defined as:
(defun handler (widget call-data &rest client-data) .... )
The call-data is packaged into a structure and passed as a single argument
and the user is allowed to register any number of items to be passed to the
callback as client-data. Being able to pass several items of client-data
is more convenient for the programmer and the packaging of the call-data
information is more appealing than splitting it apart into separate
arguments. Also, CLM only transports a limited subset of the available
callback information. We transport all information. Event handlers differ
in the same way. The client-data is the &rest arg and the event info is
packaged as a single object. Accessing the generating event in a callback
handler is done in the following manner:
(defun handler (widget call-data &rest client-data)
(with-callback-event (event call-data)
;; Access slots of event such as:
;; (event-window event) or
;; (button-event-x event)
))
Thank you very much!
I guess the ball is now to the CLM/GINA folks to make it useable with
CMUCL (sorry for the soccer - pardon, football - metaphor :)
Happy Lisping
--
Marco Antoniotti
-------------------------------------------------------------------------------
Robotics Lab | room: 1219 - tel. #: (212) 998 3370
Courant Institute NYU | e-mail: ·······@cs.nyu.edu
...e` la semplicita` che e` difficile a farsi.
...it is simplicity that is difficult to make.
Bertholdt Brecht