--
Alex Pfister e-mail: a.pf...@doc.ic.ac.uk
--
----------------------------------------------------------
Alex Pfister e-mail: a.pf...@doc.ic.ac.uk
From: ap...@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
NNTP-Posting-Host: laotzu.doc.ic.ac.uk
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 | mar...@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
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
| First, assuming skilled and experienced programmers, on a typical
| system using a reasonable mix of io and computation, Lisp is quite
| competitive to other OO systems. It's true that it can't quite match
| C++ and other strongly and statically typed languages, in terms of raw
| speed, but it's not that far off.
is this true? with CMU CL 17f and PCL, I get faster execution, less code,
and faster compilation than I do with C++ and templates using GCC 2.7.2.
if "raw speed" includes programmer time to achieve a working system, Lisp
_cannot_ lose.
#<Erik 3034231713743323>
--
the Internet made me do it
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)
>On Feb 23, 1996 21:46:58 in article <efficiency of Lisp compared to other
>progr. lang.?>, 'ap...@doc.ic.ac.uk (Alex Pfister)' wrote:
>
>
>>
>>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?
I did some crude bench marks of Lisp vs C for a simple prime number
generator and a neural net benchmarkk. CMU Lisp actually beat sun and
gnu C for the prime number, probably because it combined a div and mod
operation, and was faster than Sun C and slightly slower than Gnu C
for the nural net.
I think the real speed issue is coding style and the types of programs
you write.
Anthony
--
Anthony Berglas
Rm 312a, Computer Science, Uni of Qld, 4072, Australia.
Uni Ph +61 7 3365 4184, Home 3391 7727, Fax 3365 1999
CSM Lair 3365 1181
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.
>In article <s08enrk...@lox.ICSI.Berkeley.EDU>
>mar...@lox.icsi.berkeley.edu (Marco Antoniotti) writes:
>> In article <4glcki$l...@frigate.doc.ic.ac.uk> ap...@doc.ic.ac.uk (Alex Pfister)
>writes:
>>
>> From: ap...@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 <crac...@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
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
: 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..
|> 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 : mato...@di.epfl.ch
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
| 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>
>In article <1996Feb26.1...@wavehh.hanse.de> crac...@wavehh.hanse.de
>(Martin Cracauer) writes:
>> pi...@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.
>>
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).
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>