: roke; scsh
Scsh 0.4
> (run (sps -l))
Ty User Status Fl Nice Prv Shr Res %M Time Child %C Proc# Command
p2. | CHILD 9868+ 628 2688 19 2.6 1 7587 ...
: roke; kcl
AKCL (Austin Kyoto Common Lisp) Version(1.257) Thu Feb 8 13:35:46 EST 1990
Contains Enhancements by W. Schelter
> (system "sps -l")
Ty User Status Fl Nice Prv Shr Res %M Time Child %C Proc# Command
p2. | CHILD 10 1376+1328 820 6 0.3 0 7593 ...
Gee, it's a big mother, isn't it? We thought we'd exercise all those dark,
unused corners in your memory subsystems.
Your numbers don't show the size of the data, they show the size of the
*heaps*. Now, to be fair, I have to admit: you can run scsh with smaller
heaps, but it's still going to need bigger heaps than Ibuki CL, because AKCL
compiles to C, so none of the system runtime is actually sitting in the
heap. In S48, *everything* sits in the heap, which the GC merrily copies back
and forth for fun.
We were *this* close to getting the static heap linker into release 0.4, which
would move all the debugging tables and byte-codes down into the text pages,
where they'd quietly lurk on your disk until needed, shared by all scsh
processes on the system. But Halloween came, and the module file integration
just wasn't happening, and we were not willing to wait any longer, so here you
are. Waddling in style.
I'm thinking we need a week or two to shake out transients from this
major release -- bogus little Makefile problems like the Sun archive
file lossage we just fixed. We really want to make scsh painless
to install, and that is a tall order, since scsh, by design, touches
just about every feature Unix has got. Carlstrom is now more of an
autoconfig wizard than he ever wanted to be.
After that, though, we'll integrate the static linker with scsh and
release it. I'm hoping that'll really slim down on the memory footprint.
I might add the following. For some time now, I have been lobbying
the S48 guys on the importance of memory-mapped, shared-page library
linking, and static heap linking. Never get anywhere. I would say that
scsh is one of the top two largest, most serious uses of S48 out there,
and the critics are unanimous: too much memory. You might send email
to the S48 lists and complain about it. Here, let me help you:
scheme-48@martigny.ai.mit.edu
How about punting S48 and moving to another Scheme platform? Wow, that
would be a ton of work -- we'd have to completely redo the I/O system,
the ff interface, and the whole top-level, for starters. We'd lose S48's
module system. And what system would we use?
- Guile?
Not all there. Doesn't have S48's module system. Pure interpreter;
no compiler at all. Not complete R4RS, I think.
- There's a nice system being developed by Paul Wilson and another guy down
in Texas, I forget the name, That has potential.
- A port to Stalin would let you generate small, lean standalone binaries.
But Stalin is very alpha right now.
- ??? Frankly, the main problem is that a lot of the heavy hitters
have moved on to ML. Sussman's group at MIT has *one* guy hacking
MIT Scheme.
I miss T -- it was a very sophisticated system; more so than most of the
current crop of Scheme implementations, ten years down the line: native code
compiler, object system, pickler, all the little niceties.
The NEC guys are very good, and they are working with S48. I keep
plugging along, burning the megabytes, hoping they'll come up to
speed with a good native-code compiler. It may happen.
-Olin
|