3 ms·

Well, for comparison "Hello World" in Common Lisp, using SBCL on x64 Linux creates a ~70 Mb binary, but nobody would ever claim it's small :-) Unfortunately, f

Well, for comparison "Hello World" in Common Lisp, using SBCL on x64 Linux creates a ~70 Mb binary, but nobody would ever claim it's small :-) Unfortunately, for an arbitrary CL program it's impossible to tell for sure how much of the CL compiler and standard library it will need at run time, so SBCL takes the easy route and just includes everything. Some of the commercial Lisp compilers are a lot smarter at stripping things out and and can create significantly smaller executables. I usually avoid the issue altogether by not building binaries and running most things from the REPL or using a "#!/usr/bin/lisp --script" shebang line.

gkya 10y ago
SBCL does not create binaries per se, but dumps the program image. While it practically is a binary, it's not equal to an executable that a conventional compiler/linker produces.
- SolarNet 10y ago
  Except without a better way to package a binary it will be compared as one.
- jlarocco 10y ago
  That distinction isn't important here, though. It is the reason the resulting file is so big, but for all practical purposes it's a binary that statically links the full CL runtime.
- throwaway91111 10y ago
  I wonder why tree shaking is so ineffective. Is that because any symbol could be accessed dynamically at runtime?
  - jfoutz 10y ago
    eval is the root of all evil. String to symbol lets you introduce anything.
    - gkya 10y ago
      In lisp eval does not take a string as its input, but a form, i.e. a linked list, containing the program to execute. Maybe you confuse it with JavaScript or Python eval (or the like) where the function both reads in a string and runs the program it parsed from that string. There are diverse functions to convert a string to a symbol in different lisps.
      - jfoutz 10y ago
        Perhaps i'm rusty. in this case (funcall #'+ 1 2 3) or the more scheme-ish (apply '+ '(1 2 3)) i think the symbol plus gets evaluated to #<function+> and then is called with 1 2 3 - CL will do apply, of course, not sure about scheme and funcall. I'm totally willing to accept my mental model is wrong, i don't have an interpreter handy. So if that's true, you run into this problem: (funcall (string->symbol "+") 1 2 3) (apply (string->symbol "+") '(1 2 3)) maybe string->symbol does not introduce in to the function namespace, but i bet there's a way or a flag to do it. so anyway, at the end, you run into this problem: (funcall (string->symbol "any-random-function") 1 2 3) (apply (string->symbol "any-random-function") '(1 2 3)) this makes tree shaking hard. you could, of course, look for the handful of ways to bind symbols to functions, maybe do constant folding and include a minimal set if the compiler can prove what's actually needed. but in general i think tree shaking is hard when you can load things like that dynamically.
        lispm 10y ago
        (funcall #'+ ...) does not do a symbol lookup and does not need to retrieve the function from a symbol in Common Lisp. (funcall '+ ...) would retrieve the function from the symbol. Treeshakers are generally used for application delivery in Lisp. When you do that, then one usually limits the amount of use of runtime dynamics. Typically you can tell the treeshaker what to remove or what to keep: the compiler, the symbol table, debugging info, etc etc. Allegro CL and LispWorks have extensive facilities for this. http://franz.com/support/documentation/10.0/doc/delivery.htm http://franz.com/support/documentation/10.0/doc/delivery.htm http://www.lispworks.com/documentation/lw70/DV/html/delivery.htm http://www.lispworks.com/documentation/lw70/DV/html/delivery...
  - lispm 10y ago
    SBCL does treeshaking? I thought it just dumps the image.
    - throwaway91111 10y ago
      Well that would explain it. Any idea why they don't tree shake?
      - lispm 10y ago
        Because no one wrote one. There were some attempts but nothing which would work now. Delivering small applications does not seem to be a focus of SBCL users. https://www.snellman.net/blog/archive/2005-07-06.html https://www.snellman.net/blog/archive/2005-07-06.html There is also the possibility to compress the image. See :compression option when saving an image: http://www.sbcl.org/manual/#index-g_t_0040sbext_007bsave_002dlisp_002dand_002ddie_007d-7 http://www.sbcl.org/manual/#index-g_t_0040sbext_007bsave_002... Commercial Lisp implementations like LispWorks and Allegro CL have a treeshaker for delivery, but that's not too surprising, since these products are for developers of applications and the users pay for such features.
lispm 10y ago
Some CL compilers even don't save an image. An extreme example is mocl. mocl applications for a 64bit iPad start at 1 MB size. Other examples of CL compilers not saving an image are ECL and WCL. The ECL manual had the terminology a bit wrong, but it actually does not dump an image. https://common-lisp.net/project/ecl/static/manual/ch34.html#Internals-What-can-ECL-do- https://common-lisp.net/project/ecl/static/manual/ch34.html#... WCL: https://github.com/wadehennessey/wcl https://github.com/wadehennessey/wcl > For example, the executable for a Lisp version of the canonical ``Hello World!'' program requires only 20k bytes on 32 bit x86 Linux.

gkya 10y ago

SBCL does not create binaries per se, but dumps the program image. While it practically is a binary, it's not equal to an executable that a conventional compiler/linker produces.

SolarNet 10y ago
Except without a better way to package a binary it will be compared as one.
jlarocco 10y ago
That distinction isn't important here, though. It is the reason the resulting file is so big, but for all practical purposes it's a binary that statically links the full CL runtime.
throwaway91111 10y ago
I wonder why tree shaking is so ineffective. Is that because any symbol could be accessed dynamically at runtime?
- jfoutz 10y ago
  eval is the root of all evil. String to symbol lets you introduce anything.
  - gkya 10y ago
    In lisp eval does not take a string as its input, but a form, i.e. a linked list, containing the program to execute. Maybe you confuse it with JavaScript or Python eval (or the like) where the function both reads in a string and runs the program it parsed from that string. There are diverse functions to convert a string to a symbol in different lisps.
    - jfoutz 10y ago
      Perhaps i'm rusty. in this case (funcall #'+ 1 2 3) or the more scheme-ish (apply '+ '(1 2 3)) i think the symbol plus gets evaluated to #<function+> and then is called with 1 2 3 - CL will do apply, of course, not sure about scheme and funcall. I'm totally willing to accept my mental model is wrong, i don't have an interpreter handy. So if that's true, you run into this problem: (funcall (string->symbol "+") 1 2 3) (apply (string->symbol "+") '(1 2 3)) maybe string->symbol does not introduce in to the function namespace, but i bet there's a way or a flag to do it. so anyway, at the end, you run into this problem: (funcall (string->symbol "any-random-function") 1 2 3) (apply (string->symbol "any-random-function") '(1 2 3)) this makes tree shaking hard. you could, of course, look for the handful of ways to bind symbols to functions, maybe do constant folding and include a minimal set if the compiler can prove what's actually needed. but in general i think tree shaking is hard when you can load things like that dynamically.
      - lispm 10y ago
        (funcall #'+ ...) does not do a symbol lookup and does not need to retrieve the function from a symbol in Common Lisp. (funcall '+ ...) would retrieve the function from the symbol. Treeshakers are generally used for application delivery in Lisp. When you do that, then one usually limits the amount of use of runtime dynamics. Typically you can tell the treeshaker what to remove or what to keep: the compiler, the symbol table, debugging info, etc etc. Allegro CL and LispWorks have extensive facilities for this. http://franz.com/support/documentation/10.0/doc/delivery.htm http://franz.com/support/documentation/10.0/doc/delivery.htm http://www.lispworks.com/documentation/lw70/DV/html/delivery.htm http://www.lispworks.com/documentation/lw70/DV/html/delivery...
- lispm 10y ago
  SBCL does treeshaking? I thought it just dumps the image.
  - throwaway91111 10y ago
    Well that would explain it. Any idea why they don't tree shake?
    - lispm 10y ago
      Because no one wrote one. There were some attempts but nothing which would work now. Delivering small applications does not seem to be a focus of SBCL users. https://www.snellman.net/blog/archive/2005-07-06.html https://www.snellman.net/blog/archive/2005-07-06.html There is also the possibility to compress the image. See :compression option when saving an image: http://www.sbcl.org/manual/#index-g_t_0040sbext_007bsave_002dlisp_002dand_002ddie_007d-7 http://www.sbcl.org/manual/#index-g_t_0040sbext_007bsave_002... Commercial Lisp implementations like LispWorks and Allegro CL have a treeshaker for delivery, but that's not too surprising, since these products are for developers of applications and the users pay for such features.

lispm 10y ago

Some CL compilers even don't save an image. An extreme example is mocl. mocl applications for a 64bit iPad start at 1 MB size. Other examples of CL compilers not saving an image are ECL and WCL. The ECL manual had the terminology a bit wrong, but it actually does not dump an image. https://common-lisp.net/project/ecl/static/manual/ch34.html#Internals-What-can-ECL-do- https://common-lisp.net/project/ecl/static/manual/ch34.html#... WCL: https://github.com/wadehennessey/wcl https://github.com/wadehennessey/wcl > For example, the executable for a Lisp version of the canonical ``Hello World!'' program requires only 20k bytes on 32 bit x86 Linux.