off-topic: Why is lisp so weird?

[Pascal Bourguignon]

I had this stupid benchmark lying around anyway:

http://www.cvgpr.uni-mannheim.de/heiler/microbench/

It clearly shows that Lisp outperforms C++ in times of execution speed
in one test. Happy?

What is stupid is to benchmark the processor time, instead of
benchmarking the programmer time!

The processors of most of the computers I use or administrate are
constantly at 90+% of idle time (hopefully used gratiously by nice
background processes). Why do you think Apple spends their time
adding useless graphic animations to their user interface? They've
got nothing better to keep their processors buzy!

The only valid benchmark is how soon can a Lisp programmer produce a
valid program vs. how soon can a C programmer produce a program that
does not crash half the time.

 

[Matthias]

I've always wondered about that. I've been hearing for years how
Fortran is faster than - or as fast as - C, and it seems strange. As
fast as, I'm not concerned about. Faster than... I'd be interested in
how and why, from a purely academic perspective.

One reason: Fortran guarantees that aliasing between arrays does not
occur. For instance, in the loop

for (i = 0; i < 100; ++i) {
c = a[i-1] + b[i+1];
}

Fortran would not allow that c, a, and b point to identical memory
locations. This knowledge allows the compiler to do better
optimization in some cases. If recall correctly, the new C99 standard
introduces a "restrict" keyword which tells the C compiler to assume
non-aliasing arrays.

 

[Corey Murtagh]

I had this stupid benchmark lying around anyway:

http://www.cvgpr.uni-mannheim.de/heiler/microbench/

It clearly shows that Lisp outperforms C++ in times of execution speed
in one test. Happy?

To quote exchange.lsp:

(declaim (optimize (speed 3)
(compilation-speed 0)
(safety 0)
(debug 0)))

I guess we'll just have to assume you used similar options for the other
tests. I'd still like to see some timing done of the internal execution
time, since startup times in such a small test are likely to sway the
test results somewhat, expecially since you're using iostreams in the
C++ variant.

And you should know by now that I'm /never/ happy

 

[Corey Murtagh]

Corey> ...which proves that it is slow, no?

No it doesn't, it only proves that it is a little slower than C which
is fast enough. And when it isn't you put the critical part of the
code into C or assembly or microcode, just as a C programmer would.

A matter of referrents and definitions really. 10% slower than the
equivalent in another language may well fit many definitions of 'slow' :>

Corey> Brainf*ck has fewer keywords... are you saying that it's a simple
Corey> language? Wow. There's a bold statement for you.

Not that I know Brainf*ck or that it matters, but I was merely
challenging the thinking that the size of the language translates to
the complexity of it. If there was such a causality, you could claim
Lisp to be simpler than C which probably wasn't what nobody was trying
to say.

Hey, you snipped the bit where I was agreeing with you :>

Language complexity can't be readily measured in terms of specification
size, number of keywords, etc. Closer might be the size of the minimum
syntax description in whatever form. I'd tend to add the size of the
required [by the standard] RTL, although I'd weight that fairly low.
After all, you have to know the libraries you're working with to get the
most out of the language, right?

(And I never said that I wasn't a fanatic, but at least I am a fanatic
with a superior language)

lol

 

[David Kastrup]

I've always wondered about that. I've been hearing for years how
Fortran is faster than - or as fast as - C, and it seems strange. As
fast as, I'm not concerned about. Faster than... I'd be interested in
how and why, from a purely academic perspective.

One reason: Fortran guarantees that aliasing between arrays does not
occur. For instance, in the loop

for (i = 0; i < 100; ++i) {
c = a[i-1] + b[i+1];
}

Fortran would not allow that c, a, and b point to identical memory
locations. This knowledge allows the compiler to do better
optimization in some cases. If recall correctly, the new C99 standard
introduces a "restrict" keyword which tells the C compiler to assume
non-aliasing arrays.

Don't tell me that you'll find any programmer going to the pain of
writing things like

void arrmult(int n, int m, int l,
double (* restrict result)[l],
double const (* restrict a)[m],
double const (* restrict b)[l])
{
int i,j,k;
double sum;
for (i=0; i<n; i++)
for (k=0; k<l; k++) {
result[k] = 0.0;
for (j=0; j<m; j++)
result[k] += a[j]*b[j][k];
}
}

instead of the (mostly) equivalent

SUBROUTINE ARRMULT(N,M,L,RESULT,A,B)
INTEGER N,M,L,I,J,K
REAL*8 RESULT,A,B
DIMENSION RESULT(N,L),A(N,M),B(M,L)
DO 10 K=1,L
DO 10 I=1,N
RESULT(I,K)=0.0
DO 10 J=1,M
10 RESULT(I,K) = RESULT(I,K) + A(I,J) * B(J,K)
RETURN
END

The problem is that "restrict" can only apply to pointers, not to
arrays (even though arrays _are_ passed as pointers). That means
that you have to revert to pointer syntax.

The problem is that most good mathematicians tend to be bozo
programmers. The bozo Fortran version happens to be efficient (and
has been such for several decades). The bozo C version not. And the
efficient version could not be written until just recently.

All the old hands in mathematics have no clue about C9x.

 

[Corey Murtagh]

What is stupid is to benchmark the processor time, instead of
benchmarking the programmer time!

While the time taken to create a program is important, it can be just as
important to know that the program when completed will execute as
efficiently as possible... which with some languages is almost
guaranteed to be false. The two /should/ perhaps be weighed together
since separately they aren't very useful statistics.

The processors of most of the computers I use or administrate are
constantly at 90+% of idle time (hopefully used gratiously by nice
background processes). Why do you think Apple spends their time
adding useless graphic animations to their user interface? They've
got nothing better to keep their processors buzy!

Now run a game, or a graphics app, or a sound processing app, or... you
should have the idea by now. My computer often runs at 100% CPU because
I often do things that require it. If 10% of those CPU cycles are being
wasted because the programs are written in an inefficient language, I'd
be pissed. As it is a huge enough number of CPU cycles are being wasted
by the OS, and I'm fairly unhappy about that.

The only valid benchmark is how soon can a Lisp programmer produce a
valid program vs. how soon can a C programmer produce a program that
does not crash half the time.

For any reasonably simple coding task a competent C programmer (RH for
instance) will quite likely produce bug-free code very quickly indeed.

Really people, it's foolish to keep bringing up the horrible errors that
/can/ be made in C as being proof that C is inherently flawed. Just
because millions of C neophytes - and yes, many experienced C
programmers - have produced buggy C code is no proof that people of
similar skill level are incapable of producing buggy code in other
languages.

(As a side-point: I'm involved in a sport with a huge potential for
serious injury. Statistically however it's safer than golf... and we
all know how hazardous a sport /that/ is.)

 

[Matthias]

To quote exchange.lsp:

(declaim (optimize (speed 3)
(compilation-speed 0)
(safety 0)
(debug 0)))

I guess we'll just have to assume you used similar options for the
other tests.

No, you don't have to assume anything: The web-page tells you
_explicitly_, which compilers and which compiler switches were used.

I'd still like to see some timing done of the internal
execution time, since startup times in such a small test are likely to
sway the test results somewhat

The source code is on the page. Go ahead.

expecially since you're using iostreams in the C++ variant.

iostream is how IO is done in c++.

 

[Claudio Puviani]

What is stupid is to benchmark the processor time, instead of
benchmarking the programmer time!

The processors of most of the computers I use or administrate are
constantly at 90+% of idle time (hopefully used gratiously by nice
background processes). Why do you think Apple spends their time
adding useless graphic animations to their user interface? They've
got nothing better to keep their processors buzy!

The only valid benchmark is how soon can a Lisp programmer produce a
valid program vs. how soon can a C programmer produce a program that
does not crash half the time.

You're making the common mistake of applying your criteria to measure other
people's needs. Maybe you don't need to squeeze as much out of your CPUs, but
it's naive to believe that everyone is in the same boat as you. In my own field
(financial systems), we have budgetary and space constraints that prevent us
from arbitrarily buying new systems. This results in the existing systems being
run to the maximum of their capacity most of the time. Having software that's
more efficient -- both by design and by using more efficient tools and
languages -- lets us do more on finite resources. That's for our operational
software. On the research side, there are various problems such as searching
through N-spaces, optimizations of various kinds, etc. that also use close to
100% of the CPU of whatever system we run them on. Again, efficiency allows us
to do more with what's available. If we can get 1% better results that our
competitors by being more efficient, this more than pays for the programmer
time. In fact, trying to economize programmer time in such cases can be too
costly.

So please abstain from coming down a mountain with stone tablets that
proselytize your personal and limited experiences as dogma from which only
"stupid" people deviate.

Claudio Puviani

 

[Rahul Jain]

After all, you have to know the libraries you're working with to get the
most out of the language, right?

Not really. There are large parts of Lisp that I have (mostly) ignored,
since either I use libraries that abstract over them or I just don't
need those features regularly. For the rare occasions when I do need
them, they're available for me to use and well-specified (ok, it's
actually, the badly-specified bits that I tend to avoid the most,
surprisingly enough) so that I can quickly write what I need while
referring to the spec for guidance.

A fair bit of what I've been doing lately is actually language-building,
so the existing libraries are really only useful when they provide data
structures that happen to be useful in my language extensions or when
they let me better mesh my language constructs with those already in
Lisp or those provided by others.

 

[Raymond Toy]

Corey> Now run a game, or a graphics app, or a sound processing app,
Corey> or... you should have the idea by now. My computer often runs at 100%
Corey> CPU because I often do things that require it. If 10% of those CPU
Corey> cycles are being wasted because the programs are written in an
Corey> inefficient language, I'd be pissed. As it is a huge enough number of

How would you know 10% is being wasted? How do you know it's not 50%?
0.001%?

Ray

 

[David Steuber]

If you'd like we can all get together and write code in our language
of choice to perform a variety of common algos, find some sucker to
run all the samples sequentially on one computer, and see which
languages excell at which tasks. If Lisp comes out faster than the
'main-stream' languages in any of those tests, we'll reconsider your
objection.

There's a thought. I propose as one benchmark calculating all the
Fibonacci numbers less than 10^100000 and then printing out the
largest number calculated. I'm still a learner, but here is my
code:

(let ((max-f (expt 10 100000)))
(do ((a 1 b) (b 1 (+ a b)))
((>= b max-f) b)))

When the above expression returns, the next Fibonacci number past
10^100000 is printed. 'a contains a number less than max-f.

Java has a class for dealing with large ints, so that should be no
problem with the standard language. C has libraries available for
large integer arithmetic even though they are not standard.

I tested the above Lisp with OpenMCL although I did not time it. It
revs up the CPU fan on my PowerBook G4.

 

[Rayiner Hashem]

1. The fastest Lisp implementations are slow

Must be because it is interpreted. That and the fact that everything
is a list.


I don't understand why anyone would design a language without
putting emphasis on acceptance by the masses. Visual Basic is what we
all should be programming in! There are literally *millions* of
professional programmers who use it. That and Perl.


Exactly! Same as algebra or biology.


Commmon Lisp about 1400 pages
C++ (1998) 776 pages
Perl about 600 pages
Java Language Specification, second edition, 544 pages

Intercal - about 40 pages

Too funny! I especially like the Intercal reference

 

[Paul Wallich]

While the time taken to create a program is important, it can be just as
important to know that the program when completed will execute as
efficiently as possible... which with some languages is almost
guaranteed to be false.

Well, no. It's guaranteed to be false with all languages with the
possible exception of VHDL.

Once you start down the road of "as efficiently as possible given some
set of caveats known only to me, and subject to change depending on
perceived requirements" it's very difficult to find a principled
stopping place. Wall-clock time from spec to first error-free production
run (if finite) is one reasonable number, but it's not really principled
either.

paul

 

[Christopher C. Stacy]

Corey> Now run a game, or a graphics app, or a sound processing app,
Corey> or... you should have the idea by now. My computer often runs at 100%
Corey> CPU because I often do things that require it. If 10% of those CPU
Corey> cycles are being wasted because the programs are written in an
Corey> inefficient language, I'd be pissed. As it is a huge enough number of

Raymond> How would you know 10% is being wasted? How do you know it's not 50%?
Raymond> 0.001%?

Or that the CPU meter is really showing you the truth? How much of
the machine is that GUI CPU meter in the corner using, anyway?
And how do you know that C++ is not wasting those cycles?
Or that 10% is significant compared to what's being wasted by the OS?
Or that 10% is significant at all?

There are certainly some speed-critical things in the world,
but analyzing them is more subtle than most people seem to think.

Anyway, if speed of execution is the most important thing to
your application, then Lisp may not be the best choice.
Lisp performs okay (or even "well"), but speed is not
what it is optimized for.

 

[Christopher C. Stacy]

On Mon, 01 Mar 2004 21:42:57 GMT, Claudio Puviani ("Claudio") writes:

Claudio> You're making the common mistake of applying your criteria
Claudio> to measure other people's needs. Maybe you don't need to
Claudio> squeeze as much out of your CPUs, but it's naive to believe
Claudio> that everyone is in the same boat as you.

That is very well put, and a good point.

Claudio> In my own field (financial systems), we have budgetary and
Claudio> space constraints that prevent us from arbitrarily buying
Claudio> new systems.

I would be very surprised if an accurate cost analysis had really
been made using the kind of information we're talking about here,
if for no other reason than that it's very difficult to identify
and quantify those things.

Most people most of the time are incompetent to do that, and just
middle along, and really just bullshitting about all that stuff.
Moreover, they also commonly employ such analysis as a smokescreen
for their own problems and political adgendas.

Besides, most such technical management business decisions (in all
domains, not just the financial services sector) are knowingly based
on non-technical criteria, anyway. Some bozo somewhere has decided
that the a particular technology is today's panacea, or that business
needs to be done with a particular vendor because of their reputation,
track record, company stability, or special deals or special contacts.

 

[Pascal Bourguignon]

You're making the common mistake of applying your criteria to measure other
people's needs.

No I'm not.

It's the other people who try to apply _their_ criteria to lisp. It
would not matter if it was impossible to have a lisp implementation
running fast enough to control a large hadron collider, of small
enough to fit the 4-bit processor of my washing machine. That's why
assembler and C are for.

You could want to compare the performance of python implementations
vs. lisp implementations, or between lisp implementations and scheme
implementations.

But it's meaningless to try to do it between C/C++ and Lisp (unless
you include lpp or ecl on one side, and another Common-Lisp
implementation on the other side).

 

[Joe Marshall]

Joe> Fortran isn't.

Clearly, the Best Language is machine code.

Um, I dunno. Berlin and Surati were able to get a factor of 6 over
optimized Fortran using the `Supercomputer Toolkit'. The code was
able to achieve a better than a 12 MFlops sustained rate.
Hand-optimized Fortran for the same processor was only able to get 2
MFlops.

Oh wait. I forget to mention the language. Scheme.

@inproceedings{ berlin94partial,
author = "A. A. Berlin and R. J. Surati",
title = "Partial Evaluation for Scientific Computing: The Supercomputer Toolkit Experience",
booktitle = "Partial Evaluation and Seman\-tics-Based Program Manipulation, Orlando, Florida, June 1994 (Technical Report 94/9, Department of Computer Science, University of Melbourne)",
pages = "133--141",
year = "1994",
url = "citeseer.ist.psu.edu/berlin94partial.html" }

 

[David Magda]

(As a side-point: I'm involved in a sport with a huge potential for
serious injury. Statistically however it's safer than golf... and
we all know how hazardous a sport /that/ is.)

Statistically lawn bowling is the safest I think, followed by fencing
of all things. (I'm not sure whether all styles of fencing (epee,
sabre, foil (what's the one in the Norse tradition?)) were counted
together or whether one style is safer.)

 

[Tayssir John Gabbour]

Commmon Lisp about 1400 pages
C++ (1998) 776 pages
Perl about 600 pages
Java Language Specification, second edition, 544 pages

Intercal - about 40 pages

You remind me...

- Guy Steele made the interesting claim in the following video that
it's good to have what was once the largest spec and the smallest one.
(Common Lisp and Scheme respectively.)
http://www.ai.mit.edu/projects/dynlangs/wizards-panels.html

- If you add in something like the Javadocs, that'll pump up the code
heavily. And for those languages defined by a canonical
implementation, like Python, the pages of sourcecode should also be
considered.

For highly stylized languages, you probably want to add all the
tutorials and usenet posts needed to figure out the One True Way to
solve common problems. You wouldn't believe all the stuff my brain
accumulated while using Java. Fortunately Emacs is capable of
remembering a lot of Java patterns for me.

 

[a]

Christian Lynbech wrote:
....

...which proves that it is slow, no?

Wow! I can't believe you saw through our sleight of hand! The jig is up,
Lispers. Time to stop using Lisp. He figured us out. He's got us cold. Darn!
Just when I was about to get that VC money, too. Couldn't you have waited
another month?

Since it helps to prove that Lisp is slow it's hardly vital information.
Feel free to pull it out if you want though.

Heh! I like how you really put it to the Lisp zealot! Brilliant! And that
"feel free" comment, so offhand and casual but cutting like a knife! You
really know how to form a logical argument. I especially appreciate how you
eschew emotion for a logical development of facts, of which you demonstrate
a firm grasp.

If you'd like we can all get together and write code in our language of
choice to perform a variety of common algos, find some sucker to run all
the samples sequentially on one computer, and see which languages excell
at which tasks. If Lisp comes out faster than the 'main-stream'
languages in any of those tests, we'll reconsider your objection.

http://weitz.de/cl-ppcre/#performance

Since you put so much stake in performance issues, and since you are
intellectually honest and honorable, I expect you now to start posting to
Perl forums about how much Perl sucks, since Common Lisp kicks Perl's
you-know-what in so many of the performance tests. Yeah. Performance tests,
that's what makes a language great. No 10% slack cut for any reason
whatsoever. Run-time performance, that's the only worthwhile measure. Anyone
who thinks otherwise is simply begging to be insulted. I can see that, now
that you have posted your logical arguments and conclusions. You make it all
so clear to me. Now that I think about it, every application in the world
depends upon a 10% CPU performance edge when compared to C! Bash clearly
is out now and RedHat and Debian will have to replace all their Bash scripts
with C programs in their next release. Thank you! I just hadn't thought
about it that way. All applications are the same! You make me realize there
is simply nothing else to consider in the world other than CPU performance.
Thank you! Bless you! Really! Bless you!
....

When was the last time you found a niche market screaming out for a Lisp
solution? A solution that could /only/ be implemented in Lisp?

You seem to enjoy flaming those who like programming in Lisp more tthan you
enjoy spending time programming in your favorite language. What is your
favorite language? Do you think it should be my favorite language, too? I am
sure your opinion is correct!

=

This could be because there aren't many Lisp-related jobs. Wonder why
that is?

The average programmer is much too smart to think that Lisp is a good
language choice. Only dumb and inferior people enjoy Lisp. Lisp is a bad
choice for the average programmer, who cannot afford the silliness and
stupidity of Lisp. Everyone who uses Lisp is too stupid to see what how
incredibly inferior Lisp is as a programming language. What is the average
IQ of a professional Lisp programmer, 70 or 80? It obviously is much lower
than the IQ of an average professional programmer.

Your clear and logical arguments have made it obvious that it's not just a
personality difference. There's no way that Lisp programmers simply enjoy
something you don't enjoy. It is not like they like anchovies and you don't.
If that were the case, since you are intellectually honest and honorable,
you might feel obligated to go flame in alt.i.like.anchovies for a while.
Oh, I forgot, anchovies take 10% longer to eat than grouper. Of course
anchovies are no good. Can you show me the stats on the fastest-to-eat fish?
That's the fish I want to eat from now on!

Thanks to your argument, I now know that the most popular car in the world
must be the best car in the world! The most popular music in the world must
be the best music in the world! The most popular beer in the world must be
the best beer in the world! There is no room for any other beer! Long live
the most popular beer! Down with all the other beer! You have shown me the
lite!

....

...that don't run very fast :>

Faster than Perl. Do you hate Perl? Are you making anti-Perl posts to the
Perl newsgroups? Back off your emotion and make fully-rational posts, in
which you make logical arguments and concede logical points made by those
with whom you debate, or accept that your emotions rule your existance and
that you have no ability to make fully-rational posts.

....

Find me an open-source Lisp compiler that produces native executables
that works on Windows, Linux and Mac... maybe Solaris too, just for fun.

Do you think the evolution of computer science is at its zenith and whatever
does not exist today does not exist because of eternal qualities, never to
be altered? The lack of exactly the implementation you desire is a valid
condemnation of a language specification.

You're very rational. You marshall your arguments well. You present all the
relevant facts. You have an organized thought process. I am very impressed
with the materials you have presented.