[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A Dylan implemented on Common Lisp
- To: firstname.lastname@example.org
- Subject: Re: A Dylan implemented on Common Lisp
- From: email@example.com (Thomas Breuel)
- Date: Fri, 17 Mar 1995 00:42:01 GMT
- Organization: NETCOM On-line services
- References: <firstname.lastname@example.org>
- Sender: email@example.com
In article <firstname.lastname@example.org> Erik Naggum <email@example.com> writes:
| you may not recall that I tried to show the C fans that their "small
| footprint" C programs actually incur shared libraries, memory allocation,
| etc, on behalf of the program that rocket their 50K "disk image" into much
| larger memory images, and enjoy special operating system support that other
| languages will have to put in shared libraries.
First of all, under Linux, a shared library "hello, world" program is
15k, a statically linked program is 43k.
Second, saying that there is "special operating system support" for C
is a misrepresentation. C libraries often have stub routines to make
OS calls using a non-C calling convention C compatible. That doesn't
take a lot of overhead in C, and it shouldn't take a lot of overhead
in any language.
OS interfacing does take a lot of code and reduce efficiency in
CommonLisp because CommonLisp isn't just content with interfacing with
the OS. Instead, it isolates the programmer from the OS.
| I guess the reason for the
| confusion is that people can't differentiate "program" from "process".
| programs sit on disk, processes run in memory. I think the latter is more
| important than the former, as disk is still _way_ cheaper than RAM, so I
| consider disk footprint to be red herring.
"hello, world" in C has a SIZE of 28kbytes and an RSS of 128kbytes
under Linux. By modern standards, that seems pretty modest. Of
course, much more space efficient implementations have existed in the