From: ·····@labs-n.bbn.com
Subject: RE: C is faster than lisp (lisp vs c++ / Rick Graham...)
Date:
Message-ID: <33i7s2$fc7@info-server.bbn.com>
In article <·················@martigny.ai.mit.edu> ···@zurich.ai.mit.edu (William G. Dubuque) writes:
--> From: ·····@labs-n.bbn.com
--> Date: 18 Aug 1994 19:36:55 GMT
--> ...
--> some years ago, when i was porting Macsyma to the Explorer, I fiddled
--> with cons-areas, wondering if I could do a better job of controlling GC
--> occurrences myself. the idea was that I would allocate an area, work in
--> it, copy a result out of it and immediately free the area, avoiding
--> having to GC that area, cutting the cost of a GC when it finally did
--> occur. this was before generational GC had become available. Macsyma
--> is/was horrible about generating garbage.
-->
--> The problem of "intermediate expression swell" is innate in many
--> computer algebra calculations and is not necessarily specific to
that may be so, but DOE-Macsyma had/has some godawful code in it. a lot,
really. some of the ugliest code I ever saw. (maybe I'd like it better
now, but back then I didn't...)
--> Macsyma. In fact Macsyma was one of the driving forces behind Moon's
--> original ephemeral GC implementation for MIT Lispms, as well as many
--> other features of MacLisp/Lispm-lisp that made their way into CLtL2.
Macsyma was clearly the driver for a variety of things in Lisp, Lispms,
etc. no argument there. when I was working on it, the Explorer didn't
yet have ephemeral GC, and even with 128MB virtual workspace, I had to
let it GC pretty often, on some more interesting problems (things other
than just multiplying polys...).
--> Of course once can optimize using temporary consing areas, but if you
--> go too far you are almost doing the same thing as you would in
--> C with malloc/free.
yep. if you have a program which generates that much garbage, you either
need to change the algorithm (no chance i could even begin to do that),
or change the alloc/free mechanism. I thought I had a better chance of
doing that...but the overall project ended up getting killed under
budget cuts...
-- clint
In article <··········@info-server.bbn.com> ·····@labs-n.bbn.com writes:
From: ·····@labs-n.bbn.com
Date: 25 Aug 1994 13:55:14 GMT
In article <·················@martigny.ai.mit.edu> ···@zurich.ai.mit.edu (William G. Dubuque) writes:
--> From: ·····@labs-n.bbn.com
--> Date: 18 Aug 1994 19:36:55 GMT
--> ...
--> some years ago, when i was porting Macsyma to the Explorer, I fiddled
--> with cons-areas, wondering if I could do a better job of controlling GC
--> occurrences myself. the idea was that I would allocate an area, work in
--> it, copy a result out of it and immediately free the area, avoiding
--> having to GC that area, cutting the cost of a GC when it finally did
--> occur. this was before generational GC had become available. Macsyma
--> is/was horrible about generating garbage.
-->
--> The problem of "intermediate expression swell" is innate in many
--> computer algebra calculations and is not necessarily specific to
that may be so, but DOE-Macsyma had/has some godawful code in it. a lot,
really. some of the ugliest code I ever saw. (maybe I'd like it better
now, but back then I didn't...)
The MIT/Symbolics version was cleaned up considerably, especially when
it was ported to CL by Kent Pitman. You should realize that Macsyma
development started back in the late 60's before it was even known
how to structure large software systems.
--> Macsyma. In fact Macsyma was one of the driving forces behind Moon's
--> original ephemeral GC implementation for MIT Lispms, as well as many
--> other features of MacLisp/Lispm-lisp that made their way into CLtL2.
Macsyma was clearly the driver for a variety of things in Lisp, Lispms,
etc. no argument there. when I was working on it, the Explorer didn't
yet have ephemeral GC, and even with 128MB virtual workspace, I had to
let it GC pretty often, on some more interesting problems (things other
than just multiplying polys...).
--> Of course once can optimize using temporary consing areas, but if you
--> go too far you are almost doing the same thing as you would in
--> C with malloc/free.
yep. if you have a program which generates that much garbage, you either
need to change the algorithm (no chance i could even begin to do that),
or change the alloc/free mechanism. I thought I had a better chance of
doing that...but the overall project ended up getting killed under
budget cuts...
Unfortunately for many basic computer-algebra algorithms you can prove
that they are inherently expensive in terms of time/space. For
example, the Grobner basis algorithm, which is fundamental for
working in quotients of polynomial rings (i.e. polynomial equations),
is doubly-exponential in the worst case.