Why does Lisp (SBCL) produce so huge executables? - lisp

På Sat, 26 Apr 2008 14:23:27 +0200, skrev Trastabuga <lispercat@gmail.com>:

> I am a big admirer of Lisp, but it makes me wonder why the executable
> produced by SBCL (the latest version) that I use on Ubuntu, is so big?
> Now with hunchentoot and few more necessary libraries it's 95 MB and
> still growing with approx. 3 to 5MB per every added library. (And I am
> only talking about the size on the hard drive, when it gets loaded it
> takes 150MB in the memory!)
> When Lisp compiles code does it produce a machine code or still keeps
> some kind of interpreter and all that cons stuff in?
> I mean, 95MB is not a big deal these days, but still a comparable code
> in C/C++ with lots of libraries would be around 5 to 10 MB. If I had
> to give my Lisp executable to someone else they would also ask me what
> the heck I am putting in there!
> It was promised (and shown on different sites) that compiled Lisp is
> almost as efficient as C, I am wondering why does it need so much
> space on disk and memory and can it be reduced?
>
> Thank you,
> Andrew

I use LispWorks and don't recognize those large sizes.
Of course to the commercial versions of Lisp have a tree shaker that
removes unused functions and data and can remove compiler and interpreter
if desired. (To prevent people from distributing the entire LispWorks app
in their applications compile-file won't work in applications, but compile
will.)

Still my LispWorks GUI with CAPI running and with lw-add-ons and
huchecentoot loaded and running a small web app is only using about 40Mb
of memory. Consider that Java needs 50Mb just to run the compiler..

--------------
John Thingstad

> I am a big admirer of Lisp, but it makes me wonder why the executable
> produced by SBCL (the latest version) that I use on Ubuntu, is so big?

When I started learning CL (and getting the idea), I also have this
thought - wouldn't it be great to write all the programs in lisp
instead of C/C++?

But then it just doesn't work this way, you can't deliver a self-
contained hello-world CL program in under 100k.

So the thought of replacing all the ls, cat utilities weighting at
50mb each is a scary thought indeed.

Then I come to the conclusion - different tools for different jobs. CL
is just not going to be suitable for that task.

But you can get creative - I have used CL to generate C code (macros
hide all the boiler plate code from me) and that's a big win for me.

Also, if small footprint is not a constaint, CL is way more productive
than most of the mainstream languages.

It's especially good for quick prototyping and server side
programming.

Try a few questions at www.spoj.pl - using CL is like cheating.

Roll my own data structure? GC? Bignum? OOP? Pre-calculate and
populate table at read/compile time?


> Now with hunchentoot and few more necessary libraries it's 95 MB and
> still growing with approx. 3 to 5MB per every added library. (And I am
> only talking about the size on the hard drive, when it gets loaded it
> takes 150MB in the memory!)

That's SBCL. For lispworks (and ACL) they have a tree shaker

I compiled a hello-world windows program in lispworks and the
executable is around 1mb with a runtime memory footprint of around
10mb.

For free lisp, you can also try ECL (compile to C) and clisp (small
footprint but slower).

For lisp in general, Scheme implementations usually have much smaller
footprint (because the core is smaller, there's no CLOS built-in for
example).

Scheme also have a lot more implementations that are compile-to-C. I
have used chicken and it's fantastic - it has tons of libraries. I
have heard that Gambit produces very tight code. Both of these can
generate executable that are slightly bigger than a C++ program.

Cheers,
-- Mac

On Sat, 26 Apr 2008 13:57:39 -0700 (PDT), mac <emailmac@gmail.com> wrote:

> When I started learning CL (and getting the idea), I also have this
> thought - wouldn't it be great to write all the programs in lisp
> instead of C/C++?
>
> But then it just doesn't work this way, you can't deliver a self-
> contained hello-world CL program in under 100k.
>
> So the thought of replacing all the ls, cat utilities weighting at
> 50mb each is a scary thought indeed.

If you think you have to create a separate "stand-alone executable"
for each simple task, you think Unix, not Lisp.

Edi.

--

Lisp is not dead, it just smells funny.

Real email: (replace (subseq "spamtrap@agharta.de" 5) "edi")

JT> Still my LispWorks GUI with CAPI running and with lw-add-ons and
JT> huchecentoot loaded and running a small web app is only using about
JT> 40Mb of memory.

is that an achievement?
it's possible to run a "small web server" even on ZX Spectrum with 48KB RAM.

JT> Consider that Java needs 50Mb just to run the compiler..

plainly lies. Java compiler is a pretty simple and fast thing.

On Apr 26, 11:09 pm, Edi Weitz <spamt...@agharta.de> wrote:
> On Sat, 26 Apr 2008 13:57:39 -0700 (PDT), mac <email...@gmail.com> wrote:
> > When I started learning CL (and getting the idea), I also have this
> > thought - wouldn't it be great to write all the programs in lisp
> > instead of C/C++?
>
> > But then it just doesn't work this way, you can't deliver a self-
> > contained hello-world CL program in under 100k.
>
> > So the thought of replacing all the ls, cat utilities weighting at
> > 50mb each is a scary thought indeed.
>
> If you think you have to create a separate "stand-alone executable"
> for each simple task, you think Unix, not Lisp.
>
When people talk about running several applications in the same image,
what does that actually mean?

--
Mikael Jansson
http://mikael.jansson.be - now with 100% more Limp!

På Sat, 26 Apr 2008 23:37:49 +0200, skrev Mikael Jansson
<mikael.jansson@gmail.com>:

> On Apr 26, 11:09 pm, Edi Weitz <spamt...@agharta.de> wrote:
>> On Sat, 26 Apr 2008 13:57:39 -0700 (PDT), mac <email...@gmail.com>
>> wrote:
>> > When I started learning CL (and getting the idea), I also have this
>> > thought - wouldn't it be great to write all the programs in lisp
>> > instead of C/C++?
>>
>> > But then it just doesn't work this way, you can't deliver a self-
>> > contained hello-world CL program in under 100k.
>>
>> > So the thought of replacing all the ls, cat utilities weighting at
>> > 50mb each is a scary thought indeed.
>>
>> If you think you have to create a separate "stand-alone executable"
>> for each simple task, you think Unix, not Lisp.
>>
> When people talk about running several applications in the same image,
> what does that actually mean?
>
> --
> Mikael Jansson
> http://mikael.jansson.be - now with 100% more Limp!

That is not What Edi is talking about here. Remember Lisp doesn't really
have a fixed entry point. It is essentially just a nest of functions and
data. So there can be many paths trough the application and many entry
points. I can for instance runt huchentoot and startup two servers one for
my blog and one for my bugtrack system and have them both run
concurrently. In Lisp it is more common to use threads to run things
concurrently than to spawn/fork a separate process for each sub task. This
practice is common under Windows where COM shared objects typically remove
the need for running many different processes to achieve a task. So the
applications tend to large monolithic structures and yet they share code.
The same is the case for Lisp.

--------------
John Thingstad

On Sat, 26 Apr 2008 14:37:49 -0700 (PDT), Mikael Jansson <mikael.jansson@gmail.com> wrote:

> When people talk about running several applications in the same
> image, what does that actually mean?

I wasn't talking about that.

Edi.

--

Lisp is not dead, it just smells funny.

Real email: (replace (subseq "spamtrap@agharta.de" 5) "edi")

> If you think you have to create a separate "stand-alone executable"
> for each simple task, you think Unix, not Lisp.
>

Hi Edi!

I think your sentense made more sense if you correct it this way - s/
Lisp/emacs/

;-)

Cheers,
-- Mac

On Apr 26, 4:57 pm, mac <email...@gmail.com> wrote:
> > I am a big admirer of Lisp, but it makes me wonder why the executable
> > produced by SBCL (the latest version) that I use on Ubuntu, is so big?
>
> When I started learning CL (and getting the idea), I also have this
> thought - wouldn't it be great to write all the programs in lisp
> instead of C/C++?
>
> But then it just doesn't work this way, you can't deliver a self-
> contained hello-world CL program in under 100k.
>
> So the thought of replacing all the ls, cat utilities weighting at
> 50mb each is a scary thought indeed.
>
> Then I come to the conclusion - different tools for different jobs. CL
> is just not going to be suitable for that task.
>
> But you can get creative - I have used CL to generate C code (macros
> hide all the boiler plate code from me) and that's a big win for me.
>
> Also, if small footprint is not a constaint, CL is way more productive
> than most of the mainstream languages.
>
> It's especially good for quick prototyping and server side
> programming.
>
> Try a few questions atwww.spoj.pl- using CL is like cheating.
>
> Roll my own data structure? GC? Bignum? OOP? Pre-calculate and
> populate table at read/compile time?
>
> > Now with hunchentoot and few more necessary libraries it's 95 MB and
> > still growing with approx. 3 to 5MB per every added library. (And I am
> > only talking about the size on the hard drive, when it gets loaded it
> > takes 150MB in the memory!)
>
> That's SBCL. For lispworks (and ACL) they have a tree shaker
>
> I compiled a hello-world windows program in lispworks and the
> executable is around 1mb with a runtime memory footprint of around
> 10mb.
>
> For free lisp, you can also try ECL (compile to C) and clisp (small
> footprint but slower).
>
> For lisp in general, Scheme implementations usually have much smaller
> footprint (because the core is smaller, there's no CLOS built-in for
> example).
>
> Scheme also have a lot more implementations that are compile-to-C. I
> have used chicken and it's fantastic - it has tons of libraries. I
> have heard that Gambit produces very tight code. Both of these can
> generate executable that are slightly bigger than a C++ program.
>
> Cheers,
> -- Mac

I hear you, Mac, thank you. Just today I tried MzScheme and was nicely
surprised that I could write a small utility and make an exe file on
windows with a pretty small size. Also with Quack I can use Emacs for
editing. I'll definitely give Chicken a try.
Looks like there is a lot of libraries written just for MzScheme and
on the other hand tons of libs written for Chicken. What a waste of
human resources IMHO... If Scheme was standardized things would look
much brighter. Now it looks I have to make a choice about which
implementation of Scheme to use.
Why I asked this question about Lisp is because the my Web server is a
pretty old PIII 600MHz machine with just 350MB of RAM. When I run one
hunchentoot server (footprint in RAM fluctuates from 70 to 150MB) it's
OK. When I test the new code, I run another instance of server in a
separate image (not to spoil the production code!). Now with two Lisp
images running on that puny system it's almost choking! Probably if I
had upgraded my system to something newer I wouldn't have asked this
question
I'll stick to Lisp on the server side (unless Edi ports his beautiful
libs to Scheme
Still, when I think of making a GUI app on Windows (or Linux for that
matter), Scheme is a winner compared to open source implementations of
Lisp.

Andrew