From: Janis Dzerins
Subject: Common Lisp speed compared to Java and C++
Date: 
Message-ID: <89e367$mq0$1@krabis.latnet.lv>
I have read the piece at
http://www-aig.jpl.nasa.gov/public/home/gat/lisp-study.html.

The problem statement there looks too non-real-life (i.e. some might say that
it specially addresses some of the lisp's strengths although I think the
problem is quite general). So do anybody of you have any pointers to where to
look for some other benchmarks/comparisons (except the ones in Franz or
Harlequin pages all of which I have seen already).

It would be really nice to see how they compare in everyday applications (i.e.
non AI or some mission-critical or CAD like). Real numbers (startup time,
processing time/processor load, memory necessary for all image, etc.) would be
real nice.

I am pretty sure Lisp's efficiency is better than of those other languages, but
I need some numbers.

(It would be super-cool if someone uses Lisp in low-end computers (e.g. with
really limited resources, like P166 with 16Mb RAM) and could show some
numbers).

Thanks for attention.

--
jonis

From: Pierre R. Mai
Subject: Re: Common Lisp speed compared to Java and C++
Date: 
Message-ID: <87u2itqqo2.fsf@orion.dent.isdn.cs.tu-berlin.de>
Janis Dzerins <·····@mt.lv> writes:

> It would be really nice to see how they compare in everyday
> applications (i.e.  non AI or some mission-critical or CAD
> like). Real numbers (startup time, processing time/processor
> load, memory necessary for all image, etc.) would be real nice.

You most likely won't be able to get comparative numbers on real-life
applications, since noone can afford to do really comparative studies
between _independent_ implations of identical applications in various
languages.

So you'll either get non-fairly comparative numbers, like when someone 
reimplements a buggy, slow C application in Common Lisp, and lo and
behold it's much faster, more maintainable and less buggy.  But you
really can't compare those numbers, for the usual statistical and
social reasons:  Rewriting an application nearly always results in a
better program, regardless of the language.  So you'd need to 
compare this rewrite with other rewrites in C, for example, etc.

> (It would be super-cool if someone uses Lisp in low-end computers
> (e.g. with really limited resources, like P166 with 16Mb RAM) and
> could show some numbers).

I'd take a different approach:  Post what your real requirements are,
what kind of system(s) you'd like to implement, in what time-frame,
with what resources.  Then people could relate this to projects they
did, and offer you some numbers and success stories.

For example, in these days of trivially cheap memory, why would you
restrict yourself to 16MB RAM?  Unless you have very specialized
requirements (e.g. deploying on 1000 P166/16MB boxes, where the cost
to add some memory would be prohibitive), this seems not a very wise
decission, regardless of the language you'd use.

That said, I developped and ran parts of a quite non-trivial simulation
engine on an AMD 5x86-133, which had integer performance comparable to
a P90, using 64MB RAM using CMUCL under Linux.  Some years ago, I also
worked quite seriously on a 486DX/33 with 20MB with X and CMUCL and
CLISP.

Regs, Pierre.

-- 
Pierre Mai <····@acm.org>         PGP and GPG keys at your nearest Keyserver
  "One smaller motivation which, in part, stems from altruism is Microsoft-
   bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
From: Philip Nikolayev
Subject: puzzled
Date: 
Message-ID: <nor4sasef9h.fsf_-_@is03.fas.harvard.edu>
Hello!

As I'm trying to get used to list I can't stop wondering at how
different it is from C-like languages. Some things seem a lot easier
and a lot shorter and more elegant in list, while other things, which
are quite straightforward elsewhere, seem very puzzling in lisp.

For example, suppose I want to do something as simple as this. I have
two simple lists of numbers and I want to return a list that is the
result of the multiplication of each number of the first list by each
number of the second. I've fiddled with mapcars and lambdas for a
while and I'm just not getting it. How the hell do you do something
like that in lisp? Is there an elegant way? Or do I need to fiddle
with conses and cars and cdrs and recursion?

Thank you!

Philip
From: David J. Cooper
Subject: Re: puzzled
Date: 
Message-ID: <38BB643C.D6A2E56C@genworks.com>
Philip Nikolayev wrote:
> 
> For example, suppose I want to do something as simple as this. I have
> two simple lists of numbers and I want to return a list that is the
> result of the multiplication of each number of the first list by each
> number of the second.

Do you mean each number in the first list multiplied
by the corresponding number in the second list, like
this:

(mapcar #'* (list 2 3 4) (list 5 6 7))


or each number in the first list multiplied by each and
every number in the second list, like this:

(setq list1 (list 2 3 4) list2 (list 5 6 7))

(mapcar #'(lambda(num) 
            (apply #'* (cons num list2)))
         list1)

?


-dave


--
David J. Cooper Jr, Chief Engineer	Genworks International
·······@genworks.com			5777 West Maple, Suite 130
(248) 932-2512 (Genworks HQ/voicemail)	West Bloomfield, MI 48322-2268
(248) 407-0633 (pager)			http://www.genworks.com
From: Philip Nikolayev
Subject: Re: puzzled
Date: 
Message-ID: <nor3dqcecvj.fsf@is03.fas.harvard.edu>
"David J. Cooper" <·······@genworks.com> writes:

> Philip Nikolayev wrote:
> > 
> > For example, suppose I want to do something as simple as this. I have
> > two simple lists of numbers and I want to return a list that is the
> > result of the multiplication of each number of the first list by each
> > number of the second.
> 
> Do you mean each number in the first list multiplied
> by the corresponding number in the second list, like
> this:
> 
> (mapcar #'* (list 2 3 4) (list 5 6 7))

Thanks, David! I men the second option:

> or each number in the first list multiplied by each and
> every number in the second list, like this:
> 
> (setq list1 (list 2 3 4) list2 (list 5 6 7))
> 
> (mapcar #'(lambda(num) 
>             (apply #'* (cons num list2)))
>          list1)
> 
> ?

But this doesn't seem to work:

> (setq list1 (list 2 3 4) list2 (list 5 6 7))
(5 6 7)
>
(mapcar #'(lambda(num)
            (apply #'* (cons num list2)))
         list1)
(420 630 840)
>

Whereas I need (10 12 14 15 18 21 20 24 28)...

How can I get that?

Philip
From: Russell Senior
Subject: Re: puzzled
Date: 
Message-ID: <867lfophrx.fsf@coulee.tdb.com>
>>>>> "Philip" == Philip Nikolayev <·······@is03.fas.harvard.edu> writes:

Philip> Whereas I need (10 12 14 15 18 21 20 24 28)...

Philip> How can I get that?

Here are two ways:

   (loop for i in list1 
         append (loop for j in list2
                      collect (* i j)))
   
   (mapcan (lambda (x) 
             (mapcar (lambda (y) (* x y)) 
                     list2))
           list1)

-- 
Russell Senior         ``The two chiefs turned to each other.        
·······@aracnet.com      Bellison uncorked a flood of horrible       
                         profanity, which, translated meant, `This is
                         extremely unusual.' ''                      
From: Robert Monfera
Subject: Re: Common Lisp speed compared to Java and C++
Date: 
Message-ID: <38BEEA35.91BC7784@fisec.com>
Janis Dzerins wrote:


> The problem statement there looks too non-real-life (i.e. some might
> say that it specially addresses some of the lisp's strengths

Like problem solving?

In fact, the benchmark was originally used to test Java vs. C, and the
Lisp round was only an afterthought.

> (It would be super-cool if someone uses Lisp in low-end computers (e.g. with
> really limited resources, like P166 with 16Mb RAM) and could show some
> numbers).


Just a few days ago someone came with a similar request, which you
should have read (ng servers hold messages for several days) - look at
the responses he got on why obtaining benchmarks on non-trivial code is
non-trivial.

(There is a Lisp version for the Palm, and also for the Apple Newton.
You might want to check out those, although both of them are bytecode
interpreters.)


Robert
From: Philip Nikolayev
Subject: keywords
Date: 
Message-ID: <norsny8vpsr.fsf_-_@is01.fas.harvard.edu>
Hello!

I'm trying to get a hang on how to write functions that use keywords,
but the textbook I'm using (Graham) does not really explain this. 

For example, when I try to run this

(defun adjust-node-avail-colors (node color &key action)
  (cond ((eq action :add)
	     (put node 'avail-colors (cons color (get node 'avail-colors))))
		(T    ;default to drop
		 (put node 'avail-colors (remove color (get node 'avail-colors))))))

with 

> (adjust-node-avail-colors 'a 'red :drop)

I get the message that keyword arguments for ADJUST-NODE-AVAIL-COLORS
should occur pairwise. I'm not really sure what this means. Could
someone please explain what's wrong? Please pardon a newbie.

Thank you kindly!

Philip
From: Barry Margolin
Subject: Re: keywords
Date: 
Message-ID: <PqEv4.49$NC6.1033@burlma1-snr2>
In article <··················@is01.fas.harvard.edu>,
Philip Nikolayev  <·······@is01.fas.harvard.edu> wrote:
>I'm trying to get a hang on how to write functions that use keywords,
>but the textbook I'm using (Graham) does not really explain this. 
>
>For example, when I try to run this
>
>(defun adjust-node-avail-colors (node color &key action)
>  (cond ((eq action :add)
>	     (put node 'avail-colors (cons color (get node 'avail-colors))))
>		(T    ;default to drop
>		 (put node 'avail-colors (remove color (get node 'avail-colors))))))
>
>with 
>
>> (adjust-node-avail-colors 'a 'red :drop)
>
>I get the message that keyword arguments for ADJUST-NODE-AVAIL-COLORS
>should occur pairwise. I'm not really sure what this means. Could
>someone please explain what's wrong? Please pardon a newbie.

When you say "&key action", you're specifying that the caller supplies this
parameter by using the :action keyword, e.g.

(adjust-node-avail-colors 'a 'red :action :drop)

The point of keywords is to allow you to have lots of optional variables
without having to supply all the missing ones to get to the last one.  For
instance:

(defun make-array (dimensions &key element-type initial-element
                                   initial-contents adjustable fill-pointer
                                   displaced-to displaced-index-offset)
  ...)

If they were &optional instead of &key, then to specify that an array is
adjustable you would have to supply the element-type, initial-element, and
initial-contents options as well.  And you would have to remember the order
of all the options to the function.

P.S. Why is this linked into the "Common Lisp compared to Java" thread?
Please start a new thread if you're not continuing a discussion, don't use
a Reply or Followup command.

-- 
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
From: Philip Nikolayev
Subject: Re: keywords
Date: 
Message-ID: <norr9dsvoak.fsf@is01.fas.harvard.edu>
Thanks so much, Barry!

Philip
From: Paolo Amoroso
Subject: Re: Common Lisp speed compared to Java and C++
Date: 
Message-ID: <BIq=OCdlq2s1nsQRM7zS0N8Snipj@4ax.com>
On Thu, 02 Mar 2000 17:24:53 -0500, Robert Monfera <·······@fisec.com>
wrote:

> (There is a Lisp version for the Palm, and also for the Apple Newton.

LispMe, a Scheme system, is available for the Palm (requires Palm OS 3.0 or
later):

  http://www.lispme.de/lispme/


Paolo
-- 
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
From: David Hanley
Subject: Re: Common Lisp speed compared to Java and C++
Date: 
Message-ID: <38BEEB45.48B8A719@ncgr.org>
I had a small app I havd to write about 8 months back which
I "prototyped" in lisp then did in C.  The lisp version was faster.
I crossposted this to comp.lang.lisp and comp.lang.c++.
It's not a full-sized application, but it was interesting to me.

http://x25.deja.com/viewthread.xp?AN=454981433&search=thread&svcclass=dnserver&ST=PS&CONTEXT=952039499.520618008&HIT_CONTEXT=952039499.520618008&HIT_NUM=14&·····························@source.netcom.com%3e%231/1&group=comp.lang.lisp&frpage=getdoc.xp&back=clarinet

It seems that with a good compiler lisp is very competitive with C
for most apps.  Some things will be faster in C.  Some things will
be faster in lisp by dint of it's being easier to do what you want, and
certian of it's features ( gc, macros, etc ).  It seems like in large C
apps I've worked on we ended up duplicating certian lisp features
(poorly) and accepted innefficent code in certian places where it
would have been trivial to do it "the right way" in lisp, but it was
hard to do it "the right way" in C.  I recently had to write some java code
to take an array, and generate a new array of the same type which
had all elements of the first one removed which did not fit a certian
criteria.  Easy in lisp; a pain in C and you can't really share it if you
want to use a different function or work on a different type of
array.  So you duplicate it a few times.  Yuck!

dave