From: Tim Bradshaw
Subject: Things you don't need to worry about any more...
Date: 
Message-ID: <fbc0f5d1.0111061110.744e89f4@posting.google.com>
I have an application which needs to (or anyway does) compile `macros'
on the fly.  I've been worrying away to myself about this because I
want the whole thing to run pretty fast and I don't want to wait for
ages for the compiler each time.  In my current test file I have
things setup so that the bit of code that needs to be compiled is
fairly minimal, and just calls out into precompiled code.  There is
also a facility to put these macros into a file which is read once and
then reuse the compiled stuff.

I ran some benchmarks today, and for a small chunk of stuff with one
macro I get about 7ms to process the whole thing, including the call
to COMPILE.

I did some more experiments and it looks like compiling a small
function takes about 2-3 ms for me (obviously varies between
implementations and obviously machine-dependent, this is for a
not-particularly-state-of-the-art laptop).  Compiling a fairly hairy
function - 60 lines with three internal functions - seems to take
30-60 ms.  So really, the only reason to keep the main drag of the
macro out of the main file is that I get better indentation support if
the filename ends in .lisp...

I guess this is yet another thing, like GC cost, and large image
sizes, which has now disappeared in the noise.

--tim

From: Roger Corman
Subject: Re: Things you don't need to worry about any more...
Date: 
Message-ID: <3be98426.559512476@news.callatg.com>
On 6 Nov 2001 11:10:48 -0800, ··········@tfeb.org (Tim Bradshaw) wrote:
>
>I did some more experiments and it looks like compiling a small
>function takes about 2-3 ms for me (obviously varies between
>implementations and obviously machine-dependent, this is for a
>not-particularly-state-of-the-art laptop).  Compiling a fairly hairy
>function - 60 lines with three internal functions - seems to take
>30-60 ms.  So really, the only reason to keep the main drag of the
>macro out of the main file is that I get better indentation support if
>the filename ends in .lisp...
>
>I guess this is yet another thing, like GC cost, and large image
>sizes, which has now disappeared in the noise.
>
I agree with this. On Corman Lisp, I get a time of .2 ms (that's .0002 seconds)
to compile a simple function, and 1-2 ms to compile larger functions with
embedded flets. That's why I implemented EVAL using COMPILE. Nobody
has ever complained (to me) about the EVAL speed.

There are probably a very few real-world applications where an interpreter would
win (genetic programming comes to mind) but these can be handled (as Koza did in
his book) by creating a small, specialized interpreter for the specific
application. This is very easy to do in common lisp.

I think these times are really noise, by and large. When I think about how much
time Microsoft applications take to start, reading all those registry entries...

As an aside, people like Java for its cross-platform abilities. I think a common
lisp source file is smaller than the equivalent java .class file would be, may
network more efficiently (being text), and loads and compiles faster than a Java
VM can load and initialize the class. That's my experience anyway.

Of course you are sending source, rather than a binary, and some people are
against open source. If you have ever used Jad (Java Decompiler) you know that
basically source is equivalent to the .class file. Distributing a compiled java
class hides nothing from your competitors. The first time I used it on my own
code I actually thought I had made a mistake, because the output from Jad looked
so much like my original source I thought it actually was.

Roger
From: Thomas F. Burdick
Subject: Re: Things you don't need to worry about any more...
Date: 
Message-ID: <xcv4ro68bms.fsf@conquest.OCF.Berkeley.EDU>
·····@corman.net (Roger Corman) writes:

> On 6 Nov 2001 11:10:48 -0800, ··········@tfeb.org (Tim Bradshaw) wrote:
> >
> >I did some more experiments and it looks like compiling a small
> >function takes about 2-3 ms for me (obviously varies between
> >implementations and obviously machine-dependent, this is for a
> >not-particularly-state-of-the-art laptop).  Compiling a fairly hairy
> >function - 60 lines with three internal functions - seems to take
> >30-60 ms.  So really, the only reason to keep the main drag of the
> >macro out of the main file is that I get better indentation support if
> >the filename ends in .lisp...
> >
> >I guess this is yet another thing, like GC cost, and large image
> >sizes, which has now disappeared in the noise.

(hmm, for reasonable Lisp systems.  The Lisp compiler I'm working on
compiles via g++, and MAN is that slow!  It's a short trip from
Lisp->C++, but that's just the beginning :)

 [...]
> Of course you are sending source, rather than a binary, and some
> people are against open source. If you have ever used Jad (Java
> Decompiler) you know that basically source is equivalent to the
> .class file. Distributing a compiled java class hides nothing from
> your competitors. The first time I used it on my own code I actually
> thought I had made a mistake, because the output from Jad looked so
> much like my original source I thought it actually was.

I'm sure that you could come up with some sort of application delivery
system that would so horribly obfuscate your code that the "source"
would be less useful than your average binary with debuggin symbols
left in.  Sounds better (in terms of keeping peoples' hands off your
source and in terms of developers' preference) than using Java.

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | No to Imperialist war |                        
     ,--'    _,'   | Wage class war!       |                        
    /       /      `-----------------------'                        
   (   -.  |                               
   |     ) |                               
  (`-.  '--.)                              
   `. )----'                               
From: Tim Bradshaw
Subject: Re: Things you don't need to worry about any more...
Date: 
Message-ID: <fbc0f5d1.0111080119.e8015f0@posting.google.com>
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) wrote in message news:<···············@conquest.OCF.Berkeley.EDU>...

> (hmm, for reasonable Lisp systems.  The Lisp compiler I'm working on
> compiles via g++, and MAN is that slow!  It's a short trip from
> Lisp->C++, but that's just the beginning :)

Yes, I think that sort of thing is really death, certainly for my
application (which tends to compile a fair number of stub functions on
the fly, even if it's not compiling the real code).

> I'm sure that you could come up with some sort of application delivery
> system that would so horribly obfuscate your code that the "source"
> would be less useful than your average binary with debuggin symbols
> left in.  Sounds better (in terms of keeping peoples' hands off your
> source and in terms of developers' preference) than using Java.

This system would also be useful for answering homework questions on
cll...
From: Thomas F. Burdick
Subject: Re: Things you don't need to worry about any more...
Date: 
Message-ID: <xcv1yj96nva.fsf@conquest.OCF.Berkeley.EDU>
··········@tfeb.org (Tim Bradshaw) writes:

> ···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) wrote in message news:<···············@conquest.OCF.Berkeley.EDU>...
> 
> > (hmm, for reasonable Lisp systems.  The Lisp compiler I'm working on
> > compiles via g++, and MAN is that slow!  It's a short trip from
> > Lisp->C++, but that's just the beginning :)
> 
> Yes, I think that sort of thing is really death, certainly for my
> application (which tends to compile a fair number of stub functions on
> the fly, even if it's not compiling the real code).

Yeah, it's probably going to be problematic eventually.  Which I guess
means I'll be stuck writing an interpreter.  I knew I'd need one
anyway (I can't imagine typing (* 10 5) into the repl and having it
compiled via g++ would be very fun), but I'll probably want one that's
a bit more, er, complete than what I was planning.

On a completely unrelated note :), does anyone know of a BSD-style
license or public domain, relatively efficient, portable CL
interpreter?

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | No to Imperialist war |                        
     ,--'    _,'   | Wage class war!       |                        
    /       /      `-----------------------'                        
   (   -.  |                               
   |     ) |                               
  (`-.  '--.)                              
   `. )----'                               
From: Thomas Strathmann
Subject: Re: Things you don't need to worry about any more...
Date: 
Message-ID: <slrn9v5928.5ab.thomas@adams.pdp7.org>
> On a completely unrelated note :), does anyone know of a BSD-style
> license or public domain, relatively efficient, portable CL
> interpreter?

I don't know if this is what you need but when I was searching for some
Lisp interpreter I found vslisp on sf.net. Maybe that will make you happy.


HTH,
Thomas

-- 
Thomas S. Strathmann			http://pdp7.org
Lisp - Because today is the car of the cdr of your life
From: Thomas F. Burdick
Subject: Re: Things you don't need to worry about any more...
Date: 
Message-ID: <xcvbsi5qemc.fsf@apocalypse.OCF.Berkeley.EDU>
Thomas Strathmann <······@tstrathmann.de> writes:

> > On a completely unrelated note :), does anyone know of a BSD-style
> > license or public domain, relatively efficient, portable CL
> > interpreter?
> 
> I don't know if this is what you need but when I was searching for some
> Lisp interpreter I found vslisp on sf.net. Maybe that will make you happy.

I was actually being somewhat facetious.  What would be nice would be
a real version of the classic homework problem of "using this Lisp
system, write a Lisp interpreter."  I figure I can write my own, and
if it gets confused just punt and compile the form.  But I'm some time
from actually needing this; when I do I'll go do my due dilligence,
and make a real effort to look for one.  I suppose it wouldn't be too
surprising if there were something like this in the CMU AI repository.
On the other hand, I'll need to add in all the extensions we're using.

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | No to Imperialist war |                        
     ,--'    _,'   | Wage class war!       |                        
    /       /      `-----------------------'                        
   (   -.  |                               
   |     ) |                               
  (`-.  '--.)                              
   `. )----'