From: Rainer Joswig
Subject: Re: CL (CLISP vs CMUCL) performance on Linux
Date: 
Message-ID: <joswig-ya023180001501981002490001@news.lavielle.com>
In article <··············@mute.eaglets.com>, Sam Steingold <···@usa.net> wrote:

> I just upgraded to Linux (from w32, where I had only CLISP to chose
> from) and I am trying to choose the best CL available.
> GCL compilation failed, and Allegro 4.3 doesn't support :key in
> #'reduce,

Really? What does Franz say? This should be ***easily*** patchable.
If necessary write your own reduce.
 
> Thus, as far as ***my code*** is concerned, CLISP is faster (unless
> someone would tell me how to fix GC in CMU CL to be fast :-)

GC is one weak part of CMU CL. I think people are experimenting with
generational GCs for CMU CL. Basically I always let the
system allocate more memory (GC occurs less often).

How did you compile your code? Did you enable optimization?
What did the CMU CL compiler say about types?

Btw., for a byte code compiled system, CLISP is quite fast.

Greetings,

Rainer Joswig

-- 
http://www.lavielle.com/~joswig/

From: Tim Bradshaw
Subject: Re: CL (CLISP vs CMUCL) performance on Linux
Date: 
Message-ID: <ey3btxdzh23.fsf@todday.aiai.ed.ac.uk>
* Rainer Joswig wrote:

> GC is one weak part of CMU CL. I think people are experimenting with
> generational GCs for CMU CL. Basically I always let the
> system allocate more memory (GC occurs less often).

> How did you compile your code? Did you enable optimization?
> What did the CMU CL compiler say about types?

You can make GC in CMU a lot better if you're willing to play with the GC
somewhat.  

If your program allocates a lot of fairly transient stuff then you
typically want to set the bytes consed between gcs to be much higher
-- as large as you can make it without causing paging.  Since when a
GC occurs most stuff will be garbage, and since the gc only looks at
the live stuff, you'll tend to win because it happens less.  I have a
small program that does a lot of bignum arithmetic, and it benefits
greatly from setting the gc threshold very high.  on a machine with
128Mb I run this program with *bytes-consed-between-gcs* set to
128000000 without significant paging, and it spends negligible time in
GC (1-2%?).  This is a big win over the default 2Mb value.

If you allocate a lot of permanent things -- or anyway things you
don't care if don't get picked up, then using PURIFY can help --
it'll cause everything that survives to not be looked at by the gc
again.  I've used this, but not in the recent past.

--tim
From: Erik Naggum
Subject: Re: CL (CLISP vs CMUCL) performance on Linux
Date: 
Message-ID: <3093909400487123@naggum.no>
* Sam Steingold
| I just upgraded to Linux (from w32, where I had only CLISP to chose from)
| and I am trying to choose the best CL available.  GCL compilation failed,
| and Allegro 4.3 doesn't support :key in #'reduce,

* Rainer Joswig
| Really?  What does Franz say?  This should be ***easily*** patchable.
| If necessary write your own reduce.

  well, this is what Franz, Inc, says:

Mon Sep 29 10:58:55 PDT 1997
 Patch: 0306-01.fasl
  Implements the :key argument to reduce.
 Impact: Should be minor

  I reported it as a bug the first time I actually needed it (checksum
  calculations over string buffers for various weird protocols), and it got
  fixed within a few hours with a patch available for ACL 4.3.1.  the
  normal policy of not producing patches for an old release once a new has
  been released applies, but since 4.3 for Linux is a special case, this
  means that there is no patch for ACL 4.3 for Linux.  while this is sad
  for Linux users, I'd like to point out that a bug in `run-shell-command'
  that I ran into and thought was quite serious (it quietly truncated the
  command line) got special treatment because I felt it important that
  Linux users should not suffer this bug, and, to my grateful surprise,
  Franz, Inc, agreed and patches for all 4.3 platforms were made.  please
  do check pub/patches on ftp.franz.com.

  I did code some advice around `reduce', but it's easier to write your own
  `reduce' than to use this advice if you use :start or :end or :from-end
  _and_ rely on the order that the :key function is called on elements for
  side effects or that function may signal an error on elements outside of
  the range from :start to :end.  the advice I'm currently using for 4.3
  Linux follows.  (I have set excl:*compile-advice* globally to t, so the
  advice will be compiled automatically when defined.)

(in-package :excl)

(unless (member :key (arglist #'reduce) :test #'string=)
  (defadvice reduce (support-key :before)
    (let ((key (getf (cddr arglist) :key)))
      (when key
	(remf (cddr arglist) :key)
	(setf (second arglist)
	  (map 'vector key (second arglist)))))))

  loading this piece of advice will not hurt you after you have upgraded to
  a version of Allegro CL that supports the :key argument to `reduce'
  natively, so it is at least safe in that regard, although it is not an
  attempt to make `reduce' conformant to ANSI CL and so _could_ hurt you
  before you upgrade in pathological cases.  you have been warned.
  
#:Erik
-- 
The year "98" was new 1900 years ago.  |  Help fight MULE in GNU Emacs 20!
Be year 2000 compliant, write "1998"!  |  http://sourcery.naggum.no/emacs/