There have been embedded Lisps that used less than 48KB of RAM total.
What does THIS have to do with anything previously said? Do you realize we're discussing about SBCL and state of the art lisp implementations? (which could be more aptly characterized as state of the fart lisps). But of course, you're a lisper. Tedious as it may be, I'm going to point out every illogicy of yours.
I do have 4GB of RAM
How did I guess?
however in practice the Lisp image would be using between 10-30mb of RAM, and then fluctuate up and down by a few dozen MB as the application conses and gets gc'ed.
Misinformation, and dare I say the worst kind, for its unintentional. Just because YOUR stripped down implementation under YOUR system... Let's take a look at mine;
i i i i i i i ooooo o ooooooo ooooo ooooo
I I I I I I I 8 8 8 8 8 o 8 8
I \ `+' / I 8 8 8 8 8 8
\ `-+-' / 8 8 8 ooooo 8oooo
`-__|__-' 8 8 8 8 8
| 8 o 8 8 o 8 8
------+------ ooooo 8oooooo ooo8ooo ooooo 8
Welcome to GNU CLISP 2.48 (2009-10-03) <http://clisp.cons.org/>;
Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2000
Copyright (c) Sam Steingold, Bruno Haible 2001-2009
Type :h and hit Enter for context help.
[1]> (room)
Number of garbage collections: 0
Bytes freed by GC: 0
Time spent in GC: 0
Bytes permanently allocated: 791,004
Bytes currently in use: 32,207,216
Bytes available until next GC: 401,048
Notice: bytes freed is equal 0. That's a pretty useless GC if it can't clean its own mess! the real number to look at here is the bytes in current use. Not surprising, I'm using about 32MBs just to invoke clisp, and like you said, it's the most lightweight (sic) implementation.
Let's try something now:
[7]> (prog1 t (loop repeat 1000000 collect (random 1))
t
[8]> (room)
Number of garbage collections: 2
Bytes freed by GC: 417,784
Time spent in GC: 10,000
Bytes permanently allocated: 791,004
Bytes currently in use: 32,894,888
Bytes available until next GC: 344,168
That's a +0.8MB increase, performance slowed down by the GC and a pending bag of bytes to slurp. I didn't even use the notorious CONS.
You can actually write apps that cons little or not at all, but lets be fair and say that most Lisp programmers won't write such things unless they either hit a performance wall or just need to microoptimize everything from the start (in which case they might as well be using C if they're planning to specify every little detail anyway).
In other words, lisp programmers should just use C if they want to be precise. Wonderful! We agree.
Many Lisp compilers can do memoization,
Excuse me, "many"? There's hardly 10 lisp implementations out there and I know at least two of them did not perform this optimization you talk about (in contrast with C - the bsd compiler, gcc, icc, lcc, pcc and the list goes on, and they all perform this kind of optimization). C has real software. Lisp does not - it was an ambitious project that sinked WTR.
Sure, but it's a waste of memory to only use cons cells.
Another confession came out. Keep 'em coming! Yes, cons cells are a waste of memory. I pointed that out first.
You showed you don't know Lisp very well in the previous examples,
You haven't provided a SINGLE example of my incompetence or yours. In fact, that is negative for you since you have the burden of proof, but I'll let you slack some more.
Your problems are not actual issues to any real Lisp programmer.
great way to treat criticism and a serious critic. what an asshole.