[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: C vs. Lisp
To: Barry Margolin <firstname.lastname@example.org>
Subject: C vs. Lisp
Date: Sat, 19 Jan 91 00:09:25 -0800
Date: Fri, 18 Jan 91 19:34:04 -0800
But C bashing is going too far. In many ways, C is a much more powerful
Yes, it is too easy to pick on any language with a few smart remarks.
I think discussing concrete examples and issues is good.
language than common-lisp. I can think of many non-trivial applications
that require number-crunching, text searching and sorting, and/or massive I/O
that can't afford to wait for garbage collection or consing of any sort:
Well, both C and LISP cons and garbage collect somehow. You seem
mostly concerned with I/O, and symbolics I/O is a disgrace. You should
try, for example, lucid you should be much more impressed.
Computer vision (although I am not an expert)
Hmm, we've been doing vision work in *Lisp for years.
On a CM, sure. Here I was comparing C to common-lisp, not to *Lisp. But
you probably win this one, since I can't argue with someone in the field.
Statistical Models for Natural Language
I'm not sure what this is (as opposed to other forms of Natural Language
Here I was only concerned with I/O issues, so the specific example is not
Regular expression search (a la grep)
Lisp is a natural for this! Translate the regular expression into a Lisp
expression, compile it, and then call it. Or implement it as an FSM, where
the states are implemented as alists mapping events to a function to call
and a new state.
I'm sorry, but a modification of grep can search a 3 megabyte file for a
moderately complicated regular expression, ' [a-z]*/nn [a-z]*/[^ ]* ', in
less than 3 seconds. My Lispm might take that long to open the file on
Yes opening a file does take time. I wonder why. Part of the reason
is probably that LISM file access is a lot more general (machine
independent) that UNIX's is.
Any application associated with loading large data sets into a
connection machine without a data vault
Here I'm talking about the I/O speed in bringing large data sets into the
Lispm to be used by the CM. Over a year ago, I had this complaint, and I was
sent a few low-level read/write hacks to partially solve this problem. But,
I claim that if a function isn't documented, it is an internal function that
can not be used for portability and compatibility issues. Lisp's documented
read functions are orders of magnitude more inefficient than C's documented
read functions. This comparison was quantified in detail over a year ago,
and has not been substantially improved since.
There are many situations where you want to have control over the way memory
is allocated and where in memory things get written. In the case of large
data sets, you frequently want to allocate memory in such a way that data
objects that will be compared or used together will be close together (i.e.
on the same page) in memory. Otherwise your OS goes crazy. This type of
situation (IMHO) *demands* C programming.
How do you guarantee that two objects will be on the same page in C? The
best you can do is guarantee that they'll be close together, by allocating
one big array and then carving it up yourself.
Exactly. In C, when you read large data sets into memory, you read them into a
simple character array, parse them, and write them to a large, dynamically
allocated array. Then you simply discard the character array. In Lisp, you
cons up space *each time* you read in an object, then cons up more space while
parsing the object, then you might write it to a large lisp array. But if
you read in 1 million objects, in C you use O(1) temporary storage space
which is easily discarded. In lisp, you use O(1 million) cons cells, which
must be GC'ed.
What you seem to be doing is relying on LISP's general read functions
which are easy to use but is obviously the wrong thing for your
application. Ie you never need to read in a million things and then
throw them away, you can read them in one at a time. I don't exactly
know what your C version does, but i don't see why something like it
can't be written in Common Lisp.
If you don't mind writing less clear code, you can do what you want in
Lisp. All the Common Lisps I'm familiar with implement the elements of
unsigned-byte (with a byte size up to 32) arrays as immediate data, so no
pointer chasing is done. So, you can make a big array, and then carve it
up into small arrays (perhaps using indirect arrays, if you don't mind
If I have to do this, I'd rather use C and UNIX, purely based on the response
time of the OS and the fact that documentation in C is geared toward doing this
while documentation for this in lisp is less abundant.
allocating a few extra objects) in Common Lisp. Of course, the elements of
this array can't be arbitrary objects, they can only be positive integers,
but you can write macros and functions to build some more complex data
structures out of them.
This is crucial!!! The whole concept of a (void *) in C, where you can tell
your program explicitly that you have a pointer to an unknown object and let
data-driven code process it for you. It's not as sophisticated as flavors,
but it's lightning fast, which flavors certainly aren't.
I don't understand, isn't data driven programming an easy thing to do
in LISP? How are you doing your lightning fast type dispatch?
I don't think we will get very far with this argument, because of the strength
of our opinions, but I'd be glad to continue discussing it anyway. Who knows?
Maybe one of us will have a revelation. I worked on LispMs for two years
before ever programming on a UNIX machine. Once I learned about how the UNIX
OS worked, I could never go back to the Lispm. If you take advantage of the
C system calls and the UNIX utilities, you can do magic that you could never
dream of on a Lispm. I'm convinced of this. Only because you can *run*
applications on a UNIX box in the time it takes you to *open* a file on
a LMFS. That's just insane.
This may point to one of the reasons for the preceived differrence
between Lisp and C. Maybe Lisp does too much for programmers. It is
easy to write inefficient and consful code in LISP. You would
probably never think of writing such code in C because it would be way
to hard. In C you must face every issue up front so you make much
leaner dicisions. Many exerienced Lisp programmers worry about
perfomance issues as they write, less experienced people may not.