Subject: RE: Garnet 3.0 Speedup anyone?

From: Thomas Gerard Provenzano <[email-masked]>
Date: Mon, 26 Jun 95 21:27:09 PDT

I am using Garnet 2.2 with CLISP and Linux and the application using it runs fairly 
slowly on my 486/33 with 20MB RAM.  The Garnet FAQ states that Garnet runs quite 
slowly on CLISP.  So I doubt you did anything wrong compiling it.  If you're 
looking for a faster LISP for Garnet - skip AKCL (Austin Kyoto CL) - also very 
slow.  The FAQ recommends CMU Lisp, unfortunately it doesn't run on Intel 
platforms.
-------------------------------------
Name: Thomas Gerard Provenzano
E-mail: [email-masked] (Thomas Gerard Provenzano)
Date: 06/26/95
Time: 21:27:09

This message was sent by Chameleon 
-------------------------------------

---

From: Marcus Daniels <[email-masked]>
Date: Tue, 27 Jun 1995 04:12:51 GMT

>>>>> "Thomas" == Thomas Gerard Provenzano <[email-masked]> writes:

Thomas> I am using Garnet 2.2 with CLISP and Linux and the application
Thomas> using it runs fairly slowly on my 486/33 with 20MB RAM.  

Even on 133Mhz MIPS box, Garnet with CMUCL is still fairly slow.  If
you really wanted to beat on ECL, you might be able to get Garnet
working.  I tried once, but it porting looked to be fairly messy.  If
someone exactly point to what in Garnet/CLX is so damned slow, the
solution (w.r.t CLISP enhancements) would likely be doable.
But (optimistically) I wouldn't hope for anything better than borderline
results.  And expect to employ a fast Pentium.

An alternative would be to try using CLISP's FFI with Amulet or Tk.

---

From: [email-masked]
Date: Tue, 27 Jun 1995 18:31:51 --100

Date: Tue, 27 Jun 95 06:05:54 +0200
   Originator: [email-masked]
   Reply-To: clisp-list <[email-masked]>
   Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas
   From: Marcus Daniels <[email-masked]>

   Even on 133Mhz MIPS box, Garnet with CMUCL is still fairly slow.  If
   you really wanted to beat on ECL, you might be able to get Garnet
   working.  I tried once, but it porting looked to be fairly messy.

I have ported Garnet 2.2 to ECL.
However I decided that Tk would be a better alternative: I have a prototype
which is indeed much faster than Garnet.

-- Beppe

---

From: Joachim Schrod <[email-masked]>
Date: Wed, 28 Jun 1995 11:52:57 +0200 (MESZ)

> which is indeed much faster than Garnet.

Of course, Tk is faster.

But to comparing the class-based, imperative, Tk Widget library to
the protoyp-instance based, constraint-oriented amalgam of UI tools
called Garnet is like comparing an assembler to a 4GL system. They
are on a completely different semantic level.
    It's like comparing a McDonald's hamburger to a Haeberlin dinner
-- you can eat yourselves fill with both.

IMHO, one has to experience the ease that comes with constraint-based
specification and programming-by-demonstration when one constructs
large user interfaces, and compare it to the hairy callback-based
code with (literally) thousands of unnecessary callbacks. Then,
suddenly, one wants to use Tk only for toy-UIs (those with less than
100 or 200 interaction elements [aka widgets in Tk]).

But back to the topic: Bruno Haible has made available some patches
for Garnet that might make it faster. He wrote that they concern the
hashing code primarly. I must confess I haven't looked at them, but
perhaps somebody else might report their experiences.
    A warning note, though: On a Sparc 10, Allegro CL runs Garnet 10
times faster [!] than CLISP, and even CMUCL is about 6 times faster.
I doubt that CLISP will catch up in this region by changing Lisp
code, one has to add type inference based optimization, more caching
of previous results, and native object code production. (This is not
meant to degrade the fine work of Bruno et.al. I like CLISP a lot and
use it for many of my other developments. -- It simply is not usable
for Garnet.) Remember that Garnet implements its own
prototype-instance based object system -- and every paper of the Self
group shows that such languages needs special techniques to get fast.

Tk is great for many needed GUIs for small tools. If it's sufficient
for your task, use it. But Garnet is really something different, it
targets an other problem domain.

Cheers,
	Joachim

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod			Email: [email-masked]
Computer Science Department
Technical University of Darmstadt, Germany

---

From: Marcus Daniels <[email-masked]>
Date: Thu, 29 Jun 1995 04:58:21 GMT

>>>>> "joachim" == Joachim Schrod <[email-masked]> writes:
joachim> But back to the topic: Bruno Haible has made available some
joachim> patches for Garnet that might make it faster. He wrote that
joachim> they concern the hashing code primarly. I must confess I
joachim> haven't looked at them, but perhaps somebody else might
joachim> report their experiences. 

Not much difference.  ;(

joachim> I doubt that CLISP
joachim> will catch up in this region by changing Lisp code, one hasb
joachim> to add type inference based optimization, more caching of
joachim> previous results, and native object code production.

Or add C functions to CLISP -- solely for the sake of Garnet.

Since the simplest activities in Garnet are slow, I blame CLX, and
wonder if making a CLISP-specific CLX module wouldn't go a long way
to making Garnet usable.  Any wisdom out there?

An Amulet module is surely more forward thinking.  But it is so
hard to let go...