Hey,
I read what Eric wrote, and he's not too particularly fond of CLISP,
but I must say...
I am running simultaneous processes doing exactly the same thing with
ACL and with CLISP, and this is what it looks like:
14020 cadet 1 5 0 21M 19M run 102:39 47.09% acl
14311 cadet 1 5 0 9568K 8392K run 33:56 24.60% clisp
CLISP sucks up less than half of the memory. Not only that, but it
seems faster too, though I'll be 100% sure in a few hours.
Just wanted to mention this because, jeez, a factor of two...
dave
* David Bakhash
| I read what Eric wrote, and he's not too particularly fond of CLISP,
| but I must say...
why? I stated the specific reasons for which I recommend Allegro over
CLISP. you choose to focus on something else. that's your prerogative,
but you are also being very _unspecific_ in your complaint. it looks
like you are just disappointed without really knowing why.
for some odd reason, Allegro CL can often be outperformed on simple code,
but there's _no_ penalty for writing brilliantly abstract code (other
than compile time, but Allegro CL compiles my code in separate Lisp
processes, anyway, so I don't have to wait for them). that translates
into freedom from the shackles of premature optimization. it actually
took me a long time to appreciate this property of Allegro CL, because it
is so easy to measure performance of simple code, and so hard to measure
the combined effect of not being penalized in execution speed while being
encouraged to write code optimized for solving complex problems in their
own terms. and as long as my machine is fast _enough_, it also doesn't
matter in practical terms.
however, you need to know this: if I were even remotely interested in
performance, I wouldn't have kept this 50MHz SPARCstation as my main
system. I wouldn't have gone out and recommended something you would be
so disappointed in when your real concerns surfaced if I had known that
you would come back and complain about performance -- that really doesn't
do the qualities I value very highly in software any good, does it?
looking back at what I wrote, I think you're being somewhat destructive
in your disappointed response. here's what I wrote:
it [CLISP] is also slow in some areas and very fast in others, which
skews your priorities in optimizing your code, basically away from
writing your own abstractions and using "raw Common Lisp", because it
does that really fast. it has an amazingly fast bignum implementation,
for instance. it also sports variable-length floating point numbers.
such things may matter much to some.
you obviously fall in the latter category. why aren't you aware of it?
| CLISP sucks up less than half of the memory. Not only that, but it seems
| faster too, though I'll be 100% sure in a few hours.
keeping the old adage "from one data point, you can extrapolate in all
directions" forcefully in mind, I bet you use a lot of bignums. as I
implied, if not said outright in the above quoted paragraph, I used to
appreciate CLISP for these things. then other problems quickly made
CLISP a hellish frustration, and I associated them as a price I had to
pay for bignum performance, I price I didn't want to pay at all.
| Just wanted to mention this because, jeez, a factor of two...
look, I'm sorry if I led you to believe that Allegro CL would score high
on your performance meter with your particular code. if you're
interested in raw performance, I have nothing to tell you, except to
illustrate how unrelated _my_ performance is to the performance of the
computers I use. my Internet link is slow, too, and an inexpensive
upgrade would more than double its speed, but I don't need that, because
I'm not into high-bandwidth activities like graphics or music: I simply
don't want to use my computer for entertainment, too. what matters to me
is that it is connected to the Net 86,400,000 milliseconds a day, and I'm
currently giving the telephone company a _very_ rough time for having
deprived me of about 400 seconds of connect time a day for a while, now.
the technology we use should give 100% uptime statistics (that's why I
use it instead of faster, less reliable technology), and 99.5% uptime is
intolerable for my use. the same goes for the computer and the software
I use and all the software I _write_, too. consequently, I don't work
for people who want me to squeeze the last drop of blood out of the iron,
but for people who want to be certain that the software does what they
want it to do, _only_ what they want it to do, and never _ever_ anything
else, no matter _what_ happens. that's why I cannot use C++ or Perl and
certainly cannot afford to use any Microsoft products. that's also why I
use Allegro CL for Unix, and I sometimes give Franz Inc a rough time, but
I also stay with them because they can handle it. not many companies are
able to give me what I want in today's software climate.
however, if _you_ want to measure the relative merits of Common Lisp
implementations in terms of memory size and raw performance, that's
perfectly OK with me. (just don't call on me for help.) I'm aware that
my demands on modern technology are _way_ outside the public acceptance
criteria and people can use whatever junk they want as long as I don't
have to, but you _should_ be just as aware of your priorities as I am of
mine. that way, you won't get disappointed with the advice you get from
those with different priorities than your own and you may well be
satisfied with the choices you make.
#:Erik
--
Support organized crime: use Microsoft products!
eric,
you are right in a lot of ways. first off, I do appreciate things
that run smoothly. I also have developped an affinity for the Lisp
Listeners. It's pretty amazing to me how that works. True
multi-tasking. Oh. and I don't care so much about speed, but because
the code I'm running now is highly recursive, I appreciate speed.
I don't think I was using bignums at all, though I can't be sure. I'm
pretty sure that most of my numbers were floats (of type
`long-float'. I am kinda interested in this arbitrary-precision float
type. I don't think that `long-float' is enough, because my code
keeps calculating marginal probabilities that get smaller and smaller,
and even double-precision floats end up being zero at some point.
I am a newbie. Don't take anything I say too personally or
seriously. I'm still learning a lot. I *do* appreciate your comments
and opinions, and I don't want you to ignore me in the future, because
I value your help a lot.
dave
In article <···············@hawk.bu.edu> David Bakhash <·····@bu.edu> writes:
`long-float'. I am kinda interested in this arbitrary-precision float
type. I don't think that `long-float' is enough, because my code
keeps calculating marginal probabilities that get smaller and smaller,
and even double-precision floats end up being zero at some point.
Have you considered working with the log of the numbers instead?
Sunil
On Wed, 6 May 1998 14:49:22 -0700,
Erik Naggum <······@naggum.no> wrote in comp.lang.lisp:
> (...) you _should_ be just as aware of your priorities (...)
I am tempted to quote this from Heinlein's _The_Door_Into_Summer_:
I learned that if you didn't use priorities, when the music
stopped you were left standing.
(The main character is an engineer that makes robots.)
Best regards, Vassil.
hey,
maybe I spoke too soon. I checked on my program, and it turns out
that the ACL finished a long time ago and the CLISP is still running.
there were (as far as I know) zero bignums in there. all ints were
fixnums and the rest were floats. So go figure. I gave them
exactly the same problem to crunch (w/ slightly different parameters,
which should not affect run-time execution). I guess ACL was faster
all along, at least for my program. Anyway, the reason I'd guessed
that the CLISP process would finish earlier was just a feelign that I
got when I asked the interpreters to do some smaller things (on the
order of seconds). CLISP seemed faster. But anyway, it's no big
deal. I'm just glad that these free implementations exist.
thanks for the help, guys.
dave
In article <··············@mute.eaglets.com>, Sam Steingold <···@usa.net> wrote:
> The problem with CLISP (which is also much faster than ACL at allocating
> huge lists of large chunks of data, although slower at printing them to
> file) is not speed, but standards (ANSI) compliance. This is being
> worked on now, as the author (Bruno Haible) has surrendered his
> responsibilities as a maintaner -- although he is still actively and
> benevolently involved in the development, and it is unlikely that any of
> the ANSI standards would be left out in the nearest future.
We have used CLisp and I like it. But from time to time you
run into some annoying things. My latest:
- CLOS objects will not update if you change the class ??!
- Reader syntax for arrays (#a) doesn't seem to exist ??!
It also has the usual limitation: no threads. But then - for
a lot of things it is good enough and has been useful for some
tasks you otherwise would use sh, ksh, perl, or better scsh for.
We have written a program that runs in half a dozen CLs
and currently has been deployed as a batch program using
CLISP.
--
http://www.lavielle.com/~joswig/
······@lavielle.com (Rainer Joswig) writes:
> In article <··············@mute.eaglets.com>, Sam Steingold <···@usa.net> wrote:
> It also has the usual limitation: no threads. But then - for
I'd be surprised to know this. But I *did* apropos on ``thread'' in
ACL, and nothing came up. I'm a bit shocked. That whole Lisp
Listener thing was, I thought, some kind of multi-threading.
dave
In article <···············@hawk.bu.edu>,
David Bakhash <·····@bu.edu> writes:
> ······@lavielle.com (Rainer Joswig) writes:
>
>> In article <··············@mute.eaglets.com>, Sam Steingold <···@usa.net> wrote:
>
>> It also has the usual limitation: no threads. But then - for
>
> I'd be surprised to know this. But I *did* apropos on ``thread'' in
> ACL, and nothing came up. I'm a bit shocked. That whole Lisp
> Listener thing was, I thought, some kind of multi-threading.
>
> dave
Try (apropos :process).
Mike McDonald
·······@mikemac.com
>In article <···············@hawk.bu.edu>,
> David Bakhash <·····@bu.edu> writes:
>> ······@lavielle.com (Rainer Joswig) writes:
>>
>>> In article <··············@mute.eaglets.com>, Sam Steingold
<···@usa.net> wrote:
>>
>>> It also has the usual limitation: no threads. But then - for
>>
>> I'd be surprised to know this. But I *did* apropos on ``thread'' in
>> ACL, and nothing came up. I'm a bit shocked. That whole Lisp
>> Listener thing was, I thought, some kind of multi-threading.
>>
>> dave
>
> Try (apropos :process).
Sorry, I was talking about CLisp. CLisp has no threads.
ACL has threads. In Lisp they are traditionally called "process".
On the Lisp machine processes are threads. ;-)
David Bakhash <·····@bu.edu> writes:
>
> I'd be surprised to know this. But I *did* apropos on ``thread'' in
> ACL, and nothing came up. I'm a bit shocked. That whole Lisp
> Listener thing was, I thought, some kind of multi-threading.
That's because they are called "processes" instead of "threads" in the
ACL terminology.
--
Thomas A. Russ, USC/Information Sciences Institute ···@isi.edu