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
On Apr 26, 2:23 pm, Trastabuga <·········@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.
On 26 Apr, 14:08, Karol Skocik <············@gmail.com> wrote:
> On Apr 26, 2:23 pm, Trastabuga <·········@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 ?
In article
<····································@w74g2000hsh.googlegroups.com>,
Karol Skocik <············@gmail.com> wrote:
> On Apr 26, 2:23 pm, Trastabuga <·········@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/
From: Robert Maas, http://tinyurl.com/uh3t
Subject: Re: Why does Lisp (SBCL) produce so huge executables?
Date:
Message-ID: <rem-2008apr26-014@yahoo.com>
> > 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?
> From: Karol Skocik <············@gmail.com>
> Because it packs whole runtime and compiler to the executable.
> That's not a bug, it's a feature.
But software on the PDP-10 long long ago solved this problem by
having a shared pure (readonly) upper segment containing all the
runtime code for the programming language (such as SAIL, a version
of Algol-60, or MacLisp, etc.) and a private lower segment
containing *your* application and nothing but it (except three
lines of assembly code to link the upper segment to it at startup).
So with only the lower segment stored in your individual
"executable", and only one copy of the upper shared segment in a
system directory, executables were small and proportional to the
size of your application. The compiler and runtime etc. could
easily reside in the shared upper segment in Common Lisp if the
vendor chose to implement that. One tradeoff is that the version
number of the appliation must match the version number of the upper
segment, so either the admin must keep backups of all older
versions of the upper segment in case anybody still has code that
needs them, or the application programmer must rebuild all
executables when the admin installs a new version, and all
customers must download the newest upper segment whenever new
executables ship that need it. Now if the API for the upper segment
were very stable, you might need to maintain a version match
between application and upper segment.
In regard to disk space only, it's vaguely similar to Java, where the JVM
and all the system class files are stored in a system directory just
once, only the compiled user Class files are stored on user directories.
The admin must keep backups of the JVM and system Class files for
jdk 1.2 1.3 1.4 and 1.5 in case users have compiled Class files for them.
(My unix shell ISP has only 1.2.2 currently. That's utterly old!!!
Sun doesn't maintain Web-accessible docs for that so I use 1.3 docs.)
Is there any CL vendor that takes this shared-system-stuff approach?
On Sat, 26 Apr 2008 06:08:59 -0700 (PDT), Karol Skocik
<············@gmail.com> wrote:
>On Apr 26, 2:23 pm, Trastabuga <·········@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.
This is why LISP is better than Basic.
A.L.
On Apr 26, 5:23 am, Trastabuga <·········@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.
On Apr 26, 12:28 pm, Vagif Verdi <···········@gmail.com> wrote:
> On Apr 26, 5:23 am, Trastabuga <·········@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")?
Trastabuga <·········@gmail.com> writes:
> On Apr 26, 12:28 pm, Vagif Verdi <···········@gmail.com> wrote:
>> On Apr 26, 5:23 am, Trastabuga <·········@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!"
On Apr 26, 2:06 pm, Pascal Bourguignon <····@informatimago.com> wrote:
> Trastabuga <·········@gmail.com> writes:
> > On Apr 26, 12:28 pm, Vagif Verdi <···········@gmail.com> wrote:
> >> On Apr 26, 5:23 am, Trastabuga <·········@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?
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)
> 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 Apr 26, 4:57 pm, mac <········@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
On Apr 26, 4:43 pm, Trastabuga <·········@gmail.com> wrote:
> On Apr 26, 4:57 pm, mac <········@gmail.com> wrote:
>
> 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.
Dude, 1 Gb ram costs around $30 nowadays :))
Swap your web sever machine to something newer that accepts new RAM
chips, and forget about RAM footprint.
Or if you insist using that particular computer - use php for small
footprint and easy web programming.
On Apr 26, 8:53 pm, Vagif Verdi <···········@gmail.com> wrote:
> On Apr 26, 4:43 pm, Trastabuga <·········@gmail.com> wrote:
>
> > On Apr 26, 4:57 pm, mac <········@gmail.com> wrote:
>
> > 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.
>
> Dude, 1 Gb ram costs around $30 nowadays :))
> Swap your web sever machine to something newer that accepts new RAM
> chips, and forget about RAM footprint.
>
> Or if you insist using that particular computer - use php for small
> footprint and easy web programming.
I am emotionally attached to it, it served me well for many years :)
> Also with Quack I can use Emacs for editing.
> Now it looks I have to make a choice about which implementation of Scheme to use.
I know it's kind of off topic going down this road on cll, but it
might be useful to fellow Lispers who consider to switch to scheme for
certain tasks.
Here're my experiences with various schemes.
Gambit
+ the speed daemon
- however, libraries are lacking.
PLT
+ Lots of libraries
+ Very good documentation
+ Strong community
+ Excellent IDE (if emacs isn't your thing) and have a
built-in source level debugger
+ windows/mac/linux friendly
Chicken
+ Lots of cool libraries
+ Very good documentation (searchable at callcc.org)
+ Strong community
+ Extremely easy to hack (even with the core, this is not the case
with PLT)
+ Highly portable to various CPU architectures (better than PLT)
+ Integration with C is easy as pie
+ Well thought-out POSIX and UNIX extensions - a pleasure to use
- Debugger is not very intuitive (unhelpful back trace)
- Interpreter has quite a few limitations, weak integration with emacs
(if you're used to CL's powerful REPL and SLIME, you'll be
disappointed)
- windows setup is less than ideal, you need to get msys/cygwin +
gcc/vc++ to work together (compare to PLT, just point and click to
install, click one button to compile)
+ default macro engine is defmacro instead of hygiene macro - again
one less thing for lisper to learn, but this is going to change in
the future
+ lots of CL like features, tinyCLOS, keyword/optional arguments, CL
loop - this makes it very easy to get up to speed and be productive
from the get go. I don't quite dig the recursive/PG style of coding
if
it is not necessary
I think the last 2 points sold me. It has absolutely minimal barrier
of entry for a lisper.
> 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.
Yes, sometimes you don't control the platform and you can't just put
more
RAM to the problem. I'd love to run a full CL implementation on a
modest
cell phone / calculator but that just won't happen.
> 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.
You don't know Edi is for hire? :)
Anyway, use CL when you can (more mature, better tools) but scheme
can
fit the bill better if you need smaller footprint (embedded system)
and
certain features (mandatory TCO and first class CALLCC, which I sorely
miss on the CL side)
Just my 0.02
-- Mac
From: Edi Weitz
Subject: Re: Why does Lisp (SBCL) produce so huge executables?
Date:
Message-ID: <uabjgup9s.fsf@agharta.de>
On Sat, 26 Apr 2008 16:43:29 -0700 (PDT), Trastabuga <·········@gmail.com> wrote:
> unless Edi ports his beautiful libs to Scheme
That'd require an extremely huge amount of bribe... :)
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
If I remember correctly, the last time I used ECL, hello world was
less than 10k plus the about 4 megabyte shared library.
The last time I created an executable with SBCL that contained
Hunchentoot, about 30 megabytes IIRC were being used by some arrays.
From: Edi Weitz
Subject: Re: Why does Lisp (SBCL) produce so huge executables?
Date:
Message-ID: <uzlrguxui.fsf@agharta.de>
On Sat, 26 Apr 2008 13:57:39 -0700 (PDT), mac <········@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 ·········@agharta.de" 5) "edi")
On Apr 26, 11:09 pm, Edi Weitz <········@agharta.de> wrote:
> On Sat, 26 Apr 2008 13:57:39 -0700 (PDT), mac <········@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
<··············@gmail.com>:
> On Apr 26, 11:09 pm, Edi Weitz <········@agharta.de> wrote:
>> On Sat, 26 Apr 2008 13:57:39 -0700 (PDT), mac <········@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
From: Edi Weitz
Subject: Re: Why does Lisp (SBCL) produce so huge executables?
Date:
Message-ID: <uve24uv8a.fsf@agharta.de>
On Sat, 26 Apr 2008 14:37:49 -0700 (PDT), 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 ·········@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
From: Don Geddis
Subject: Re: Why does Lisp (SBCL) produce so huge executables?
Date:
Message-ID: <87prs4l1nc.fsf@geddis.org>
mac <········@gmail.com> wrote on Sat, 26 Apr 2008:
> 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++?
There's not much point in re-writing things that work fine as is,but
I get your point.
> But then it just doesn't work this way, you can't deliver a self-
> contained hello-world CL program in under 100k.
Why is this necessarily the requirement? Why must your hello-world be
self contained?
> So the thought of replacing all the ls, cat utilities weighting at 50mb
> each is a scary thought indeed.
You realize, I hope, that many of the programs you're thinking of make
system calls to the C library that's in the OS (e.g. glibc).
What's wrong with each of your "replacement" programs merely being the tiny
compiled FASL files for the program code, and all of them sharing the same
lisp executable? Why do you define the problem to need all the huge (lisp)
libraries to be statically compiled into each individual lisp utility, but
you don't seem to mind that the C utilities share a similarly large library.
Not that there's any point to making an _identical_ copy, but is there any
problem with having your ls-in-lisp and cat-in-lisp just be tiny fasl code,
each sharing the same lisp image?
> Then I come to the conclusion - different tools for different jobs. CL
> is just not going to be suitable for that task.
Do you ever use perl scripts? Shell scripts? What's the difference?
Why is CL not suitable for such tasks, using exactly the same architecture?
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
If I was a father in a waiting room, and the nurse came out and said,
"Congratulations, it's a girl," I think a good gag would be to get real mad
and yell, "A girl!? You must have me mixed up with THAT dork!" and point to
another father. -- Deep Thoughts, by Jack Handey
mac <········@gmail.com> writes:
>> 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.
Silly seems a better term.
The average Unix shell has some set of these sorts of utilities as
built-in features, so it is frequently the case that the shell is not
unlike a Lisp REPL.
And once we have an analogy so direct, it becomes clear that the
*right* answer is NOT to create binaries for these things, but rather
to invoke them from within a Lisp environment.
I haven't done much with this in a while, but was, at one point,
building some wrappers for bits of MH and NNTP functionality in Lisp.
It wouldn't make much sense to run those functions from a Unix shell,
but it surely WOULD be logical to run them in a Lisp REPL.
In the (now-old) "Lisp Machine" environments, that was very much the
idea; you might have a huge "base executable," but it would
immediately include great gobs of stuff.
> 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.
I spent a fair bit of this week writing bits of Lisp code that was
generating SQL schemas. Nobody (aside from me) will ever see the Lisp
code; it has been a convenient way of experimentally generating a
pretty sophisticated schema.
> For lisp in general, Scheme implementations usually have much smaller
> footprint (because the core is smaller, there's no CLOS built-in for
> example).
Usually they're not that much smaller, because having useful sets of
libraries brings them back up in size to be not particularly smaller
than CL...
--
output = ("cbbrowne" ·@" "cbbrowne.com")
http://www3.sympatico.ca/cbbrowne/linuxxian.html
"Optimization hinders evolution." -- Alan J. Perlis
In article
<····································@8g2000hse.googlegroups.com>,
Trastabuga <·········@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/
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?
P� Sat, 26 Apr 2008 14:23:27 +0200, skrev Trastabuga <·········@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
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.
From: Waldek Hebisch
Subject: Re: Why does Lisp (SBCL) produce so huge executables?
Date:
Message-ID: <fv0euv$keo$1@z-news.pwr.wroc.pl>
Alex Mizrahi <········@users.sourceforge.net> wrote:
> 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.
>
Do you mean real web server? How do you connect Spectrum to the network?
And how many simultanenous connections does it support?
--
Waldek Hebisch
·······@math.uni.wroc.pl
WH> Do you mean real web server?
yes
WH> How do you connect Spectrum to the
WH> network?
via ethernet adapter
WH> And how many simultanenous connections does it support?
i dunno. at least one :).
you can easily find such sites via Google -- they have descriptions of
hardware and software etc.
e.g. here's a story at The Register about a e-commerce site that is run on
machines like spectrum:
http://www.theregister.co.uk/2007/07/07/ebuyer_runs_site_on_commodore64/
information about web server on Commodore64:
http://dunkels.com/adam/tfe/software.html
speccy aside, i'm pretty sure one can make a Common Lisp web server that
will occupy just couple of megabytes.
so 40 MB John mentions looks afwfully (order of magnitude) inoptimal.
P� Sun, 27 Apr 2008 10:43:17 +0200, skrev Alex Mizrahi
<········@users.sourceforge.net>:
> WH> Do you mean real web server?
>
> yes
>
> WH> How do you connect Spectrum to the
> WH> network?
>
> via ethernet adapter
>
> WH> And how many simultanenous connections does it support?
>
> i dunno. at least one :).
> you can easily find such sites via Google -- they have descriptions of
> hardware and software etc.
>
> e.g. here's a story at The Register about a e-commerce site that is run
> on
> machines like spectrum:
>
> http://www.theregister.co.uk/2007/07/07/ebuyer_runs_site_on_commodore64/
>
> information about web server on Commodore64:
> http://dunkels.com/adam/tfe/software.html
>
> speccy aside, i'm pretty sure one can make a Common Lisp web server that
> will occupy just couple of megabytes.
> so 40 MB John mentions looks afwfully (order of magnitude) inoptimal.
>
>
I fail to see you point. The setup I decribed was not just a web server.
It was a web server, a web app, a GUI editor, a GUI based lisp debugger, a
common lisp compiler and library..
If I stripped it down I am sure it would be much smaller.
As you know Lisp (as in CL) is to small to run on a spectrum and so what?
Cheap PC's became good quite some while ago. Why are you messing around
with antique hardware a quarter of a century old? Now that's suboptimal :)
--------------
John Thingstad
P� Sun, 27 Apr 2008 12:27:46 +0200, skrev John Thingstad
<·······@online.no>:
> As you know Lisp (as in CL) is to small to run on a spectrum and so what?
lol.. large perhaps?
--------------
John Thingstad
On Sat, 26 Apr 2008 23:47:43 +0000 (UTC) Waldek Hebisch wrote:
> Alex Mizrahi <········@users.sourceforge.net> wrote:
>> 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.
>>
>
> Do you mean real web server? How do you connect Spectrum to the network?
> And how many simultanenous connections does it support?
For a real world example look at the fnord or coronita web servers.
Some 10k (statically linked!) are enough for a web server.
David