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

This is a discussion on Why does Lisp (SBCL) produce so huge executables? - lisp ; 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 ...

+ Reply to Thread
Page 1 of 4 1 2 3 ... LastLast
Results 1 to 10 of 34

Why does Lisp (SBCL) produce so huge executables?

  1. Default Why does Lisp (SBCL) produce so huge executables?

    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

  2. Default Re: Why does Lisp (SBCL) produce so huge executables?

    On Apr 26, 2:23 pm, Trastabuga <lisper...@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?
    > 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


    Because it packs whole runtime and compiler to the executable. That's
    not a bug, it's a feature.

  3. Default Re: Why does Lisp (SBCL) produce so huge executables?

    On 26 Apr, 14:08, Karol Skocik <Karol.Sko...@gmail.com> wrote:
    > On Apr 26, 2:23 pm, Trastabuga <lisper...@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?
    > > 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

    >
    > Because it packs whole runtime and compiler to the executable. That's
    > not a bug, it's a feature.


    Does it always have to do that ? What if
    some code doesn't use eval or runtime
    compilation ?

  4. Default Re: Why does Lisp (SBCL) produce so huge executables?

    In article
    <80e5a19f-3c39-4d7d-801f-4057e4235976@8g2000hse.googlegroups.com>,
    Trastabuga <lispercat@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?
    > 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?


    Usually you can reduce space, when you get rid of most
    development information (symbol names, arglist information,
    documentation strings, source locators, ...),
    when you do less code inlining, etc. The amount of information
    that gets recorded should be controllable.
    Check the OPTIMIZE qualities of SPACE, DEBUG and SPEED.
    Less DEBUG often records less information. More SPACE lets
    the compiler optimize for space efficiency. Less SPEED will
    reduce inlining, etc. You should also check with the SBCL
    compiler guys if there are other options to reduce
    code size.

    >
    > Thank you,
    > Andrew


    Look for Clozure CL (formerly known as OpenMCL) should create much
    smaller code - still native code, but often not as fast as the
    code of SBCL. Clozure CL runs on runs on PowerPC hardware under Mac OS X
    and LinuxPPC, and on x86-64 hardware under Linux, Mac OS X, and FreeBSD.
    LispWorks also generates large code, but usually less than SBCL.
    LispWorks also has a delivery tool that can reduce code in
    applications.

    Most Lisp implementations have several ways to control
    how much development information is recorded by the compiler.

    --
    http://lispm.dyndns.org/

  5. Default Re: Why does Lisp (SBCL) produce so huge executables?

    In article
    <9fcc1b1b-fe7f-4aaa-ab12-ced203353352@w74g2000hsh.googlegroups.com>,
    Karol Skocik <Karol.Skocik@gmail.com> wrote:

    > On Apr 26, 2:23 pm, Trastabuga <lisper...@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?
    > > 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

    >
    > Because it packs whole runtime and compiler to the executable. That's
    > not a bug, it's a feature.


    Runtime and compiler don't have to be large. See Clozure CL.
    The code of SBCL is also largish - not only the (constant size)
    runtime and compiler.

    There is also the possibility to reuse those as shared
    libraries (or using other techniques) when you have several
    Lisp applications running.

    --
    http://lispm.dyndns.org/

  6. Default Re: Why does Lisp (SBCL) produce so huge executables?

    T> I mean, 95MB is not a big deal these days, but still a comparable code
    T> in C/C++ with lots of libraries would be around 5 to 10 MB.

    the difference is in dynamic nature of Lisp -- SBCL needs to take care
    about all this dynamic stuff in native code.
    at same time, it does not sacrifice speed for compactness, inlining pieces
    that could be shared and called.

    while this approach is aguable, it's not that unreasonable in modern
    realities -- nobody cares much about hundreds megabytes.

    at same time, if such size is not acceptable to you, you can try different
    implementation -- i.e. CLISP or ECL.
    if you're dealing with web programming, anyway most time will be spend in
    printing and i/o,
    so theoretically byte-code implementation shouldn't be slower than native
    one.

    T> If I had to give my Lisp executable to someone else they would also ask
    T> me what the heck I am putting in there!

    in the days of bloatware, when software is shipped on DVDs?




  7. Default Re: Why does Lisp (SBCL) produce so huge executables?

    On Apr 26, 5:23 am, Trastabuga <lisper...@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?
    > Now with hunchentoot and few more necessary libraries it's 95 MB


    I'm confused. You are actually putting a web server into client
    application ?

    If it is a server program, why create an executable at all ?
    Just pack all files into zip archive with a start script. Will be much
    smaller.

  8. Default Re: Why does Lisp (SBCL) produce so huge executables?

    On Apr 26, 12:28 pm, Vagif Verdi <Vagif.Ve...@gmail.com> wrote:
    > On Apr 26, 5:23 am, Trastabuga <lisper...@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?
    > > Now with hunchentoot and few more necessary libraries it's 95 MB

    >
    > I'm confused. You are actually putting a web server into client
    > application ?
    >
    > If it is a server program, why create an executable at all ?
    > Just pack all files into zip archive with a start script. Will be much
    > smaller.


    I save my work in an image with sb-ext:save-lisp-and-die.
    After that I load it with detachtty so I can connect to it with Emacs/
    Slime.
    Could you elaborate on how can I do it without making an image (or
    executable if I use ":executable t")?

  9. Default Re: Why does Lisp (SBCL) produce so huge executables?

    Trastabuga <lispercat@gmail.com> writes:

    > On Apr 26, 12:28 pm, Vagif Verdi <Vagif.Ve...@gmail.com> wrote:
    >> On Apr 26, 5:23 am, Trastabuga <lisper...@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?
    >> > Now with hunchentoot and few more necessary libraries it's 95 MB

    >>
    >> I'm confused. You are actually putting a web server into client
    >> application ?
    >>
    >> If it is a server program, why create an executable at all ?
    >> Just pack all files into zip archive with a start script. Will be much
    >> smaller.

    >
    > I save my work in an image with sb-ext:save-lisp-and-die.
    > After that I load it with detachtty so I can connect to it with Emacs/
    > Slime.
    > Could you elaborate on how can I do it without making an image (or
    > executable if I use ":executable t")?


    Exactly the same way you did it, but you'd stop just before
    sb-ext:save-lisp-and-die.

    Since we're talking about a long-running server process, the load and
    compilation time up front shouldn't matter.

    On the other hand, if you want quick restart times, for a high
    availability web site, then what do 100MB matter?

    It's the classical space<->time trade off.

    --
    __Pascal Bourguignon__ http://www.informatimago.com/

    "Indentation! -- I will show you how to indent when I indent your skull!"

  10. Default Re: Why does Lisp (SBCL) produce so huge executables?

    On Apr 26, 2:06 pm, Pascal Bourguignon <p...@informatimago.com> wrote:
    > Trastabuga <lisper...@gmail.com> writes:
    > > On Apr 26, 12:28 pm, Vagif Verdi <Vagif.Ve...@gmail.com> wrote:
    > >> On Apr 26, 5:23 am, Trastabuga <lisper...@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?
    > >> > Now with hunchentoot and few more necessary libraries it's 95 MB

    >
    > >> I'm confused. You are actually putting a web server into client
    > >> application ?

    >
    > >> If it is a server program, why create an executable at all ?
    > >> Just pack all files into zip archive with a start script. Will be much
    > >> smaller.

    >
    > > I save my work in an image with sb-ext:save-lisp-and-die.
    > > After that I load it with detachtty so I can connect to it with Emacs/
    > > Slime.
    > > Could you elaborate on how can I do it without making an image (or
    > > executable if I use ":executable t")?

    >
    > Exactly the same way you did it, but you'd stop just before
    > sb-ext:save-lisp-and-die.
    >
    > Since we're talking about a long-running server process, the load and
    > compilation time up front shouldn't matter.
    >
    > On the other hand, if you want quick restart times, for a high
    > availability web site, then what do 100MB matter?
    >
    > It's the classical space<->time trade off.
    >
    > --
    > __Pascal Bourguignon__ http://www.informatimago.com/
    >
    > "Indentation! -- I will show you how to indent when I indent your skull!"


    I'll try it. Will it reduce the footprint in the memory as well?

+ Reply to Thread
Page 1 of 4 1 2 3 ... LastLast