Subject: Re: compiler

From: Ricardo Aler Mur <[email-masked]>
Date: Wed, 4 Nov 1998 18:41:16 +0100 (CET)

On Thu, 22 Oct 1998, Bruno Haible wrote:

> Hmm. I estimate the speed gain of using a native compiler like CMUCL [1]
> to be a factor 5 or so.

This would be incredibly useful, as I have to carry out experiments that
last for days. I just tried cmucl and clisp with a genetic programming
system and as far as I can se, clisp is faster and uses far less memory.
There is no number crunching nor type declarations in the code, though.
Cmucl seems to spend most of its time gc-ing.

Ricardo.
--------
mailto: "Ricardo Aler Mur" <[email-masked]>
http://grial.uc3m.es/~aler

---

From: Rainer Joswig <[email-masked]>
Date: Thu, 5 Nov 1998 06:12:08 +0100

>Cmucl seems to spend most of its time gc-ing.

Typical problem with the old GC. You need to tune the
GC settings. Additionally doing less consing is another option.
I haven't tried that, but the new GC for CMUCL 18b under Linux/FreeBSD
should be better.

Rainer Joswig, Lavielle EDV Systemberatung GmbH & Co, Lotharstrasse 2b, D22041
Hamburg, Tel: +49 40 658088, Fax: +49 40 65808-202,
Email: [email-masked] , WWW: http://www.lavielle.com/~joswig/

---

From: Rodrigo Ventura <[email-masked]>
Date: Thu, 5 Nov 1998 16:51:01 GMT

>>>>> "Ricardo" == Ricardo Aler Mur <[email-masked]> writes:

    Ricardo> This would be incredibly useful, as I have to carry out experiments that
    Ricardo> last for days. I just tried cmucl and clisp with a genetic programming
    Ricardo> system and as far as I can se, clisp is faster and uses far less memory.
    Ricardo> There is no number crunching nor type declarations in the code, though.
    Ricardo> Cmucl seems to spend most of its time gc-ing.

        My experience tells me the same. I tried CMUCL a couple of
times, and in fact I got quite impressed with its speed in
small-number tight-loop algorithms. Simple numerical stuff simply
flies on CMUCL. But then I tried two programs that made CMUCL unusable
as far as my needs: a agent-based programming language for problem
solving, where it spent all the time GC'ing (there was some sort of
context switching between the agents), and a dead-simple recursive
factorial function, that made CMUCL core dump with large numbers.

        It seems that the tradeof of having assembly-level compilation
is the weakness of the memory management system. The whole CMUCL
system is quite huge, and it makes sense to ask if the extra megas of
sources (in comparasion with CLISP, for instance) do payback. Extra
complexity usually throws the expected advantage it is supposed to
bring.

        Regards,

-- 
--

*** Rodrigo Martins de Matos Ventura, alias <Yoda>
***  [email-masked], http://www.isr.ist.utl.pt/~yoda
***   Instituto de Sistemas e Robotica, Polo de Lisboa
***    Instituto Superior Tecnico, Lisboa, Portugal
***     PGP Public Key available on my homepage
*** Key fingerprint = 0C 0A 25 58 46 CF 14 99  CF 9C AF 9E 10 02 BB 2A