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

This is a discussion on Why does Lisp (SBCL) produce so huge executables? - lisp ; T> I'll try it. Will it reduce the footprint in the memory as well? i don't think there will be significant difference.. OTOH if you're using image, you can do such trick -- instruct SBCL that all the stuff in ...

+ Reply to Thread
Page 2 of 4 FirstFirst 1 2 3 4 LastLast
Results 11 to 20 of 34

Why does Lisp (SBCL) produce so huge executables?

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

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

    i don't think there will be significant difference..

    OTOH if you're using image, you can do such trick -- instruct SBCL that all
    the stuff in the image is persistent.
    then, when you load it, it won't be scanning this stuff when doing full GC,
    and so GC time can be saved.

    (but keep in mind that premature optimization is evil)



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

    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

  3. Default Re: 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?


    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

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

    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")

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

    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.



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

    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!

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

    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

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

    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")

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

    > 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

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

    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

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