I was told that compiled Prolog code is on the average about twice
as slow as comparable code written in C, Pascal.
How is the performance of Lisp compared to other programming languages?
--
Alex Pfister e-mail: ·········@doc.ic.ac.uk
--
----------------------------------------------------------
Alex Pfister e-mail: ·········@doc.ic.ac.uk
In article <··········@frigate.doc.ic.ac.uk> ····@doc.ic.ac.uk (Alex Pfister) writes:
From: ····@doc.ic.ac.uk (Alex Pfister)
Newsgroups: comp.lang.lisp
Date: 23 Feb 1996 21:46:58 GMT
Organization: Logic Programming Section, Dept of Computing, Imperial College
Lines: 10
Distribution: world
I was told that compiled Prolog code is on the average about twice
as slow as comparable code written in C, Pascal.
How is the performance of Lisp compared to other programming languages?
WARNING: FLAME BAIT AHEAD!
About as fast if you use a good compiler as CMUCL (where available).
On the other hand I just read some post elsewhere (was it
comp.lang.dylan ?!?) where ther was somebody complaining that using
the C++ STL slows the system down to about half (well, maybe a bigger
fraction :) ) the speed of a good CL implementation :)
Cheers
--
Marco Antoniotti - Resistente Umano
===============================================================================
International Computer Science Institute | ·······@icsi.berkeley.edu
1947 Center STR, Suite 600 | tel. +1 (510) 643 9153
Berkeley, CA, 94704-1198, USA | +1 (510) 642 4274 x149
===============================================================================
...it is simplicity that is difficult to make.
...e` la semplicita` che e` difficile a farsi.
Bertholdt Brecht
From: Richard Pitre
Subject: Re: efficiency of Lisp compared to other progr. lang.?
Date:
Message-ID: <4gnu92$ll8@ra.nrl.navy.mil>
In article <···············@lox.ICSI.Berkeley.EDU>
·······@lox.icsi.berkeley.edu (Marco Antoniotti) writes:
> In article <··········@frigate.doc.ic.ac.uk> ····@doc.ic.ac.uk (Alex Pfister)
writes:
>
> From: ····@doc.ic.ac.uk (Alex Pfister)
> Newsgroups: comp.lang.lisp
> Date: 23 Feb 1996 21:46:58 GMT
> Organization: Logic Programming Section, Dept of Computing, Imperial
College
> Lines: 10
> Distribution: world
>
>
> I was told that compiled Prolog code is on the average about twice
> as slow as comparable code written in C, Pascal.
> How is the performance of Lisp compared to other programming languages?
>
> WARNING: FLAME BAIT AHEAD!
>
> About as fast if you use a good compiler as CMUCL (where available).
> On the other hand I just read some post elsewhere (was it
> comp.lang.dylan ?!?) where ther was somebody complaining that using
> the C++ STL slows the system down to about half (well, maybe a bigger
> fraction :) ) the speed of a good CL implementation :)
>
> Cheers
> --
> Marco Antoniotti - Resistente Umano
>
TAKING THE BAIT
Correct me if I'm wrong about these speed tests but I think that they tend to
be done on C/Pascal turf. If on the other hand the primary data types are
expression trees of indeterminate size and there is pattern matching involved
then, before you get to the speed issue, there is a question in the minds of
many about the availability of C/Pascal programmers who can reliably generate
useful code of this type.
richard
·····@n5160d.nrl.navy.mil (Richard Pitre) writes:
>In article <···············@lox.ICSI.Berkeley.EDU>
>·······@lox.icsi.berkeley.edu (Marco Antoniotti) writes:
>> In article <··········@frigate.doc.ic.ac.uk> ····@doc.ic.ac.uk (Alex Pfister)
>writes:
>>
>> From: ····@doc.ic.ac.uk (Alex Pfister)
>> I was told that compiled Prolog code is on the average about twice
>> as slow as comparable code written in C, Pascal.
>> How is the performance of Lisp compared to other programming languages?
Good C compilers can produce as overhead-free code as C compilers does.
Two problems:
1) Modern RISC machines needs more than the shortest sequence of
instructions, they need the instructions to be sheduled in a certain
order. Usually, only the compiler writers of the chip makers can
provide optimal sheduling and they usually write C and Fortran
compilers. Even gcc has many problms in this area. Most Lisp
implementations doesn't care about sheduling at all. On Mips
systems I've seen CMUCL producing faster code than gcc for exactly the
same (floating point) algorithm.
The flip side is that a compiler like CMU CL, which has a much higher,
cleaner abstraction of the code generation process may be tuned easier
for such processors than most C compilers. gcc needs a complete new
design of an interafce, some kind of abstraction to provide the
neccessary information about each CPU's preferences. I claim this is
easier to do in Lisp.
2) CL compilers generate good code for build-in data types. But CLOS
types require dynamic lookup. C++ can do static binding and therefore
inlining. This can be a big plus when using small
objects. Additionally, the dynamic lookup of C++ is very efficient,
about twice as fast as that of ObjC (which needs two
indirections). CLOS is much worse. An additional problem is that most
(if not all) CLOS implementations arrange slots using pointers, which
causes one additional access and CPU cache trashing. As I understand,
the required flexibility of CLOS makes it difficult to lay out Slots
as direct values because one needs to be able to redefine the type of
these slots.
The right way might be too look at what Dylan does and see in what way
their sealing type system is useable in a Common Lisp
environment. Would at least require some additional semantics for
packages/modules, I think.
CL can provide good performance but you have to have performance in
mind when you start a project. Most CL programs of mine started as a
very flexible piece of code that has too many dependencies on slow
method lookup in it to change it later.
And don't forget that it requires a good Lisp compiler and a
programmer who understands his compiler. I can't claim to fall into
this category, although I usually get my programs fast enough. In C++
that is not so important.
>> About as fast if you use a good compiler as CMUCL (where available).
>> On the other hand I just read some post elsewhere (was it
>> comp.lang.dylan ?!?) where ther was somebody complaining that using
>> the C++ STL slows the system down to about half (well, maybe a bigger
>> fraction :) ) the speed of a good CL implementation :)
The STL is one of the nicest pieces of C++, IMHO. Used carefully, it
can be very useful to control the performance characteristic of a
program. I'd say "pilot error" or braindead implementation when code
slows down when using STL. Maybe someone could tell them that <MAP> is
not a hashing data type. This alone is the cause of many
slowdowns. People tend to think that a data type such as map is the
fastest possible implementation. Remember that C++ is a language that
is designed by very good people, but that the average user is much
less experienced as members of the Lisp community these days (my
impression).
>Correct me if I'm wrong about these speed tests but I think that they tend to
>be done on C/Pascal turf. If on the other hand the primary data types are
>expression trees of indeterminate size and there is pattern matching involved
>then, before you get to the speed issue, there is a question in the minds of
>many about the availability of C/Pascal programmers who can reliably generate
>useful code of this type.
Right, I think. However, you can get very far with simple data types
when using enough manpower. All this GUI stuff today is implemenated
that way. And it *is* faster than Lisp solutions (CLIM, CLIO, Garnet).
Your argument may be turned against CLOS. Using complex data types in
Common Lisp usually means loosing all support by the compiler, while
C++ doesn't care and produces the same code for "1 + 1" in most cases,
even when expressed as call to an object.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@wavehh.hanse.de> - Fax +49 40 522 85 36
BSD User Group Hamburg, Germany - No NeXTMail anymore, please.
Copyright 1995. Redistribution via Microsoft Network is prohibited
From: Richard Pitre
Subject: Re: efficiency of Lisp compared to other progr. lang.?
Date:
Message-ID: <4gtgsh$b13@ra.nrl.navy.mil>
In article <······················@wavehh.hanse.de> ········@wavehh.hanse.de
(Martin Cracauer) writes:
> ·····@n5160d.nrl.navy.mil (Richard Pitre) writes:
>
> >Correct me if I'm wrong about these speed tests but I think that they tend
to
> >be done on C/Pascal turf. If on the other hand the primary data types are
> >expression trees of indeterminate size and there is pattern matching
involved
> >then, before you get to the speed issue, there is a question in the minds of
> >many about the availability of C/Pascal programmers who can reliably
generate
> >useful code of this type.
>
> Right, I think. However, you can get very far with simple data types
> when using enough manpower. All this GUI stuff today is implemenated
> that way. And it *is* faster than Lisp solutions (CLIM, CLIO, Garnet).
>
> Your argument may be turned against CLOS. Using complex data types in
> Common Lisp usually means loosing all support by the compiler, while
> C++ doesn't care and produces the same code for "1 + 1" in most cases,
> even when expressed as call to an object.
>
The one-language-for-everything debate is not constructive. My argument will
most certainly be turned against me but then I will stop arguing, shrug, and
make sure that my wallet and my towel are secure. I confess here and now, once
and for all that you CAN do everything in anything, with dime-a-dozen
programmers and its always faster, better, cheaper, more compatible,
politically correct and finally and most importantly doable with compatible
tools that are popular. If someone really believes that they can just as easily
afford to generate and maintain a particular application in C/C++ then, true or
not, that is their financial problem. With enough money you can do it in
assembler. You can really make it cook if you can afford to have a
microcodeable chip made up. I'm sure that a true believer can easily find
significant instances where this was accomplished. Better yet, screw the
microcode, make a chip that is a digital emulation of the problem.
Outside of a few people who put a rediculously high value on their personal
time and who want to actually write code to do something rather than to be a
real CODE WARRIOR(there is actually a product named this), who needs Lisp and
Prolog?
richard
[Richard Pitre]
| Outside of a few people who put a rediculously high value on their
| personal time and who want to actually write code to do something
| rather than to be a real CODE WARRIOR, who needs Lisp and Prolog?
some of us still think programming is a form of art.
#<Erik 3034444227283610>
--
the Internet made me do it
·····@n5160d.nrl.navy.mil (Richard Pitre) writes:
>In article <······················@wavehh.hanse.de> ········@wavehh.hanse.de
>(Martin Cracauer) writes:
>> ·····@n5160d.nrl.navy.mil (Richard Pitre) writes:
>>
>> >Correct me if I'm wrong about these speed tests but I think that they tend
>to
>> >be done on C/Pascal turf. If on the other hand the primary data types are
>> >expression trees of indeterminate size and there is pattern matching
>involved
>> >then, before you get to the speed issue, there is a question in the minds of
>> >many about the availability of C/Pascal programmers who can reliably
>generate
>> >useful code of this type.
>>
>> Right, I think. However, you can get very far with simple data types
>> when using enough manpower. All this GUI stuff today is implemenated
>> that way. And it *is* faster than Lisp solutions (CLIM, CLIO, Garnet).
>>
>> Your argument may be turned against CLOS. Using complex data types in
>> Common Lisp usually means loosing all support by the compiler, while
>> C++ doesn't care and produces the same code for "1 + 1" in most cases,
>> even when expressed as call to an object.
>>
>The one-language-for-everything debate is not constructive. My argument will
>most certainly be turned against me but then I will stop arguing, shrug, and
>make sure that my wallet and my towel are secure. I confess here and now, once
>and for all that you CAN do everything in anything, with dime-a-dozen
>programmers and its always faster, better, cheaper, more compatible,
>politically correct and finally and most importantly doable with compatible
>tools that are popular. If someone really believes that they can just as easily
>afford to generate and maintain a particular application in C/C++ then, true or
>not, that is their financial problem. With enough money you can do it in
>assembler. You can really make it cook if you can afford to have a
>microcodeable chip made up. I'm sure that a true believer can easily find
>significant instances where this was accomplished. Better yet, screw the
>microcode, make a chip that is a digital emulation of the problem.
>Outside of a few people who put a rediculously high value on their personal
>time and who want to actually write code to do something rather than to be a
>real CODE WARRIOR(there is actually a product named this), who needs Lisp and
>Prolog?
I hope you didn't misunderstand me. Of course I don't advocate the
skillless programming tendencies widespread today. And actually use
Lisp for some projects I get payed for. Nothingtheless, some problems
in Lisp cause trouble for me.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@wavehh.hanse.de> - Fax +49 40 522 85 36
BSD User Group Hamburg, Germany - No NeXTMail anymore, please.
Copyright 1995. Redistribution via Microsoft Network is prohibited
From: William Ware
Subject: Re: efficiency of Lisp compared to other progr. lang.?
Date:
Message-ID: <4hik25$skt@services.xionics.com>
Richard Pitre (·····@n5160d.nrl.navy.mil) wrote:
: ... if we had a language independent standard for
: module linkeage then some of the problems with selecting an appropriate
: language for a project would vanish overnight...
I think this is the idea behind Guile (Cygnus Support) and ILU (Xerox PARC).
Here are relevant some web pointers.
ILU <ftp://ftp.parc.xerox.com/pub/ilu/ilu.html>
Guile <http://www.cygnus.com/library/ctr/guile.html>
<http://nis-www.lanl.gov/~rosalia/gnudl-doc/learn_libguile_toc.html>
From: Fernando D. Mato Mira
Subject: Re: efficiency of Lisp compared to other progr. lang.?
Date:
Message-ID: <4gusq2$jhh@info.epfl.ch>
In article <······················@wavehh.hanse.de>, ········@wavehh.hanse.de (Martin Cracauer) writes:
|> The STL is one of the nicest pieces of C++, IMHO. Used carefully, it
|> can be very useful to control the performance characteristic of a
|> program. I'd say "pilot error" or braindead implementation when code
|> slows down when using STL. Maybe someone could tell them that <MAP> is
|> not a hashing data type. This alone is the cause of many
|> slowdowns. People tend to think that a data type such as map is the
|> fastest possible implementation.
So, where are the hash tables in STL then? Or is it broken?
Regards,
--
Fernando D. Mato Mira http://ligwww.epfl.ch/matomira.html
Computer Graphics Lab
Swiss Federal Institute of Technology (EPFL) Phone : +41 (21) 693 - 5248
CH-1015 Lausanne FAX : +41 (21) 693 - 5328
Switzerland E-mail : ········@di.epfl.ch
From: Bill Newman
Subject: Re: efficiency of Lisp compared to other progr. lang.?
Date:
Message-ID: <wnewmanDnF37p.FC2@netcom.com>
Richard Pitre (·····@n5160d.nrl.navy.mil) wrote:
: In article <···············@lox.ICSI.Berkeley.EDU>
: ·······@lox.icsi.berkeley.edu (Marco Antoniotti) writes:
: > In article <··········@frigate.doc.ic.ac.uk> ····@doc.ic.ac.uk (Alex Pfister)
: writes:
: >
: > I was told that compiled Prolog code is on the average about twice
: > as slow as comparable code written in C, Pascal.
: > How is the performance of Lisp compared to other programming languages?
: >
: > WARNING: FLAME BAIT AHEAD!
: >
: > About as fast if you use a good compiler as CMUCL (where available).
: > On the other hand I just read some post elsewhere (was it
: > comp.lang.dylan ?!?) where ther was somebody complaining that using
: > the C++ STL slows the system down to about half (well, maybe a bigger
: > fraction :) ) the speed of a good CL implementation :)
: >
: > Cheers
: > --
: > Marco Antoniotti - Resistente Umano
: >
: TAKING THE BAIT
: Correct me if I'm wrong about these speed tests but I think that they tend to
: be done on C/Pascal turf. If on the other hand the primary data types are
: expression trees of indeterminate size and there is pattern matching involved
: then, before you get to the speed issue, there is a question in the minds of
: many about the availability of C/Pascal programmers who can reliably generate
: useful code of this type.
: richard
One data point to consider: the world of computer game-playing
programs (programs to play Chess, Go, Bridge, or whatever) seems to be
dominated by programs in C and increasingly C++, with critical parts
hand-coded in assembler where programmer time is available and
portability isn't an issue.
I know something about computer chess (I read the newsgroup..) and I
don't know of any programs not in C, C++, or assembler. (Except that
for a time, CRAY BLITZ used the Cray FORTRAN compiler.)
In Go (my particular interest) expansion trees of indeterminate size
and pattern matching are fundamental, and the three strongest programs
which I'm familiar with (including the current world champion and two other
programs which are almost certainly in the top ten) are
Handtalk (the current world champion and a newcomer this year, written
entirely in 80x86 assembler(!) by a chemistry professor in
mainland China);
Many Faces of Go, written in C by David Fotland at HP; he has said that
it would be in C++ if done today, but it's been around for a decade
or so and that C++ wasn't an attractive option when he started; and
Nemesis, by Bruce Wilcox, who originally wrote
the program in Lisp (as an academic project?) and ended up translating
it to C for efficiency(?) (in the early 1980's?).
These programs tend to represent on the order of 1-10 man-years of
work and perhaps 20K lines of code. Programming efficiency is often
as much of a consideration as run-time efficiency -- Go programmers
tend to play the game *much* better than their programs and have an
abundance of information about the game that they'd teach their
programs if the task could be accomplished in a reasonable amount of
time.
I'm writing my own Go-playing program (not (yet?) one of the strongest
in the world:-). I was sufficiently impressed by some of the rapid
prototyping arguments that I'd seen (and by my own experience with
small Lisp programs) that I wrote an early implementation of my
program in Lisp (actually Scheme, since that seemed like the dialect
with the best support under Linux). However, I ended up abandoning
that approach when I determined that -- for my programming style,
anyway -- it's painful to maintain code without static type checking
once it exceeds 1000 lines or so. (Also (1) I couldn't find a free
Lisp implementation which both had a decent debugger and produced
efficient compiled code (or made it easy to write primitives in C),
and (2) I found that C++ constructors and destructors are a pretty
good conceptual fit to a lot of the things which go on in my program,
and I missed them in my higher-level code.)
I'm now a little skeptical about the competitive advantages that
Richard Pitre describes. My personal experience may have been
distorted by my relative inexperience in Lisp. (I've been programming
in in C, C++, and assembler for more than 15 years, while I've only
spent months programming in Lisp.) For that matter, the relative
scarcity of successful Lisp game-playing programs may reflect the
relative Lisp inexperience of the programmer population at large.
However, the lack of conspicuous success for Lisp programs in this
field does seem to give a sort of upper bound for the competitive
advantage of Lisp as a language to express algorithms to solve this
kind of problem -- especially since one of the top ten programs was
originally written in Lisp. (BTW, I have seen marketing failures and
programmer ignorance cited as explanations for Lisp's relative
obscurity. I submit that if Lisp is just as obscure in direct
machine-to-machine contests as it is in contests mediated by
marketing, media, and purchasing droids, one must wonder about such
explanations..)
Bill Newman
PS. I still like various things about Lisp, and I particularly miss
garbage collection for early prototypes. Once I understand a problem
well enough to do a clean top-down design, C++ makes it it's pretty
easy to do without GC in 90+% of the cases I've run into so far.
However, in one complicated case I ended up writing a 500-line Lisp
prototype before I understood the problem well enough to start my C++
coding..
From: Richard Pitre
Subject: Re: efficiency of Lisp compared to other progr. lang.?
Date:
Message-ID: <4gv46u$ij0@ra.nrl.navy.mil>
In article <·················@netcom.com> ·······@netcom.com (Bill Newman)
writes:
> Richard Pitre (·····@n5160d.nrl.navy.mil) wrote:
> : In article <···············@lox.ICSI.Berkeley.EDU>
> : ·······@lox.icsi.berkeley.edu (Marco Antoniotti) writes:
> : > In article <··········@frigate.doc.ic.ac.uk> ····@doc.ic.ac.uk (Alex
Pfister)
> : writes:
> : >
> : > I was told that compiled Prolog code is on the average about twice
> : > as slow as comparable code written in C, Pascal.
> : > How is the performance of Lisp compared to other programming
languages?
> : >
> : > WARNING: FLAME BAIT AHEAD!
> : >
> : > About as fast if you use a good compiler as CMUCL (where available).
> : > On the other hand I just read some post elsewhere (was it
> : > comp.lang.dylan ?!?) where ther was somebody complaining that using
> : > the C++ STL slows the system down to about half (well, maybe a bigger
> : > fraction :) ) the speed of a good CL implementation :)
> : >
> : > Cheers
> : > --
> : > Marco Antoniotti - Resistente Umano
> : >
>
> : TAKING THE BAIT
>
> : Correct me if I'm wrong about these speed tests but I think that they tend
to
> : be done on C/Pascal turf. If on the other hand the primary data types are
> : expression trees of indeterminate size and there is pattern matching
involved
> : then, before you get to the speed issue, there is a question in the minds
of
> : many about the availability of C/Pascal programmers who can reliably
generate
> : useful code of this type.
>
> : richard
>
> One data point to consider: the world of computer game-playing
> programs (programs to play Chess, Go, Bridge, or whatever) seems to be
> dominated by programs in C and increasingly C++, with critical parts
> hand-coded in assembler where programmer time is available and
> portability isn't an issue.
>
> I know something about computer chess (I read the newsgroup..) and I
> don't know of any programs not in C, C++, or assembler. (Except that
> for a time, CRAY BLITZ used the Cray FORTRAN compiler.)
>
> In Go (my particular interest) expansion trees of indeterminate size
> and pattern matching are fundamental, and the three strongest programs
> which I'm familiar with (including the current world champion and two other
> programs which are almost certainly in the top ten) are
>
> Handtalk (the current world champion and a newcomer this year, written
> entirely in 80x86 assembler(!) by a chemistry professor in
> mainland China);
>
> Many Faces of Go, written in C by David Fotland at HP; he has said that
> it would be in C++ if done today, but it's been around for a decade
> or so and that C++ wasn't an attractive option when he started; and
>
> Nemesis, by Bruce Wilcox, who originally wrote
> the program in Lisp (as an academic project?) and ended up translating
> it to C for efficiency(?) (in the early 1980's?).
>
> These programs tend to represent on the order of 1-10 man-years of
> work and perhaps 20K lines of code. Programming efficiency is often
> as much of a consideration as run-time efficiency -- Go programmers
> tend to play the game *much* better than their programs and have an
> abundance of information about the game that they'd teach their
> programs if the task could be accomplished in a reasonable amount of
> time.
>
> I'm writing my own Go-playing program (not (yet?) one of the strongest
> in the world:-). I was sufficiently impressed by some of the rapid
> prototyping arguments that I'd seen (and by my own experience with
> small Lisp programs) that I wrote an early implementation of my
> program in Lisp (actually Scheme, since that seemed like the dialect
> with the best support under Linux). However, I ended up abandoning
> that approach when I determined that -- for my programming style,
> anyway -- it's painful to maintain code without static type checking
> once it exceeds 1000 lines or so. (Also (1) I couldn't find a free
> Lisp implementation which both had a decent debugger and produced
> efficient compiled code (or made it easy to write primitives in C),
> and (2) I found that C++ constructors and destructors are a pretty
> good conceptual fit to a lot of the things which go on in my program,
> and I missed them in my higher-level code.)
>
> I'm now a little skeptical about the competitive advantages that
> Richard Pitre describes. My personal experience may have been
> distorted by my relative inexperience in Lisp. (I've been programming
> in in C, C++, and assembler for more than 15 years, while I've only
> spent months programming in Lisp.) For that matter, the relative
> scarcity of successful Lisp game-playing programs may reflect the
> relative Lisp inexperience of the programmer population at large.
> However, the lack of conspicuous success for Lisp programs in this
> field does seem to give a sort of upper bound for the competitive
> advantage of Lisp as a language to express algorithms to solve this
> kind of problem -- especially since one of the top ten programs was
> originally written in Lisp. (BTW, I have seen marketing failures and
> programmer ignorance cited as explanations for Lisp's relative
> obscurity. I submit that if Lisp is just as obscure in direct
> machine-to-machine contests as it is in contests mediated by
> marketing, media, and purchasing droids, one must wonder about such
> explanations..)
>
> Bill Newman
>
> PS. I still like various things about Lisp, and I particularly miss
> garbage collection for early prototypes. Once I understand a problem
> well enough to do a clean top-down design, C++ makes it it's pretty
> easy to do without GC in 90+% of the cases I've run into so far.
> However, in one complicated case I ended up writing a 500-line Lisp
> prototype before I understood the problem well enough to start my C++
> coding..
Affirmation.
Many many good things are written in C and C++ and anything that can be written
can be written in C and C++. I program in C and C++ most of the time. Future
history books will tell a glorious tale of the crucial role played by C and
C++. You can never prove that history would have turned out any better without
them and the books will mostly talk about the huge successes of the victorious.
There is no doubt in my mind that you, Bill Newman, should write all of your
code in C and C++ with time critical parts written in assembler when you can
afford the time. I believe that you should ignore Lisp and Prolog like
languages. Moreover it is mostly a waste of your time, time that can be used
entertaining a C++ parser, to argue with the Lisp and Prolog dinosaur
mentalities.
richard
From: ken
Subject: Re: efficiency of Lisp compared to other progr. lang.?
Date:
Message-ID: <4hhv73$dk8@sleepy.inch.com>
Hey, Bill!
>>
the lack of conspicuous success for Lisp programs in this
field does seem to give a sort of upper bound for the competitive
advantage of Lisp as a language to express algorithms to solve this
kind of problem
<<
OK, but I think that is what some early posts were saying. In "this
field" for "this kind of problem" ... sure. For chess, go and checkers
the "squares", pieces are all represented as simple integers. Plus to do
a good job you have to sample a kazillion possibilities. I am a recent
convert to Lisp and know for a fact it is the best programming language
ever made, but when I ask myself where I would not use it, I always
think of Chess (or for image transformations done by PhotoShop).
On Feb 24, 1996 12:22:19 in article <Re: efficiency of Lisp compared to
other progr. lang.?>, ········@lox.icsi.berkeley.edu (Marco Antoniotti)'
wrote:
>WARNING: FLAME BAIT AHEAD!
>
>About as fast if you use a good compiler as CMUCL (where available).
>On the other hand I just read some post elsewhere (was it
>comp.lang.dylan ?!?) where ther was somebody complaining that using
>the C++ STL slows the system down to about half (well, maybe a bigger
>fraction :) ) the speed of a good CL implementation :)
>
I'm not a fan of STL (Sorry for talking about C++ in a Lisp group, but I
believe many Lispers are also C++'ers). All the books and articles I
read about claim how lean and mean it is, but I don't wholeheartedly
agree. When it comes to raw speed, a piece of code written at
a low level, using domain knowledge of the task at hand, nearly
always wins -- templates/generics notwithstanding.
STL is also much more complex to use than "ordinary" class
libraries. Witness all the thick books on the shelves about STL.
But I've decided to start using it since it's part of the standard...
But, to respond to Marco's post, whoever made the complaint is
wrong. Compared to other libraries, STL is generally about as
efficient and fast as its competitors. That it slows the system
down by any noticeable amount is hogwash.
Maybe the claimant is talking about compile times instead. I
can understand why a compiler will have to spend a lot more time
in its job where a large template library is involved. Precompiling
headers should eliminate much of this problem.
is referring to compile times.
--
Pete Grant
Kalevi, Inc.
Software Engineering & development
I was told that compiled Prolog code is on the average about twice
as slow as comparable code written in C, Pascal.
How is the performance of Lisp compared to other programming languages?
That depends on lots of factors:
1. Whether or not the C and Lisp versions use the same algorithm.
2. The programming style used in C and Lisp.
3. The type of problem being solved (numeric vs. symbolic vs. ...)
4. The compiler(s) being used.
5. The optimization level settings on the compilers being used.
6. Whether appropriate declarations are given in the Lisp code (if
declarations are allowed)
I have seen Lisp code that runs 35 times slower than C code and I have seen
Lisp code that runs 6 times *faster* than C code. So there is no easy answer
to your question. But I suggest that you take a look a Stalin, a highly
optimizing Scheme compiler available free from my home page. For certain
programs, particularly numeric ones, it generates code that is as good or
better than C, without any declarations.
Jeff (home page http://www.cs.toronto.edu/~qobi)
--
Jeff (home page http://www.cs.toronto.edu/~qobi)
From: Richard A. O'Keefe
Subject: Re: efficiency of Lisp compared to other progr. lang.?
Date:
Message-ID: <4grqla$6lh@goanna.cs.rmit.EDU.AU>
····@doc.ic.ac.uk (Alex Pfister) writes:
>I was told that compiled Prolog code is on the average about twice
>as slow as comparable code written in C, Pascal.
This is meaningless. Compiled by which compiler?
I use several C compilers on this SPARC, and they all have a lot of options,
and it is _easy_ to find a two-to-one speed difference between C compilers.
There are also three C compilers for this machine: p2c+c, pc, gpc, with a
somewhat wider range of speeds.
There are also lots of Prolog compilers. Aquarius Prolog is probably the
top of the line. Prolog compilers vary more than C compilers.
So, which C compiler? What Prolog compiler? What machine?
And most important of all: what program? It is not altogether clear that
there is any such animal as "comparable code written in C", comparable,
that is, to "average" (what's that?) Prolog code. How many C compilers
do well with code that backtracks? How many C compilers are good with
programs that change (not merely are augmented by loading DLLs) at run
time?
You _can_ meaningfully say "THIS compiler for C compiling THIS program
that solves THIS problem generated code that ran THIS fast on THIS
machine, compared with THIS compiler for Prolog compiling THIS program
which took THIS time." Even then, you'll probably find someone saying
"but you've written poor C and worse Prolog; try it like this instead".
>How is the performance of Lisp compared to other programming languages?
Once in order to silence a Lisp-basher I wrote two programs to solve the
same problem. One was written by me in C and was compiled with the
vendor's compiler for an Encore Multimax. The other was written by me
in Scheme and was compiled by the T system, Scheme being a Lisp dialect.
The Scheme version ran 17 times faster.
More recently, I compared a C program compiled by SPARCompiler C and by
gcc with a Scheme version compiled by Stalin. The Stalin code ran faster.
(Surprise! Stalin compiles to C, which is then compiled by GCC.)
--
Election time; but how to get Labor _out_ without letting Liberal _in_?
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.