Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon.

Pages: 1-

Minimal Lisp binaries

Name: Anonymous 2014-03-30 20:28

Nearly all lisp dialects have native code compilers, and many can produce standalone executables. One thing I don't understand however is why executables require the full run-time? especially when your code doesn't use eval. Is there a way to use create a minimal image with sbcl that only includes the functions your program uses?

Name: Anonymous 2014-03-31 11:09

It's because GC implementation takes so much space.

Also, if you could make it smaller, you couldn't make anything useful with it anyways, since the GC pauses execution in every critical moment.

Name: Anonymous 2014-03-31 19:52

>>2
Enjoy one of the following:
- cluttered code, segfaults and double frees
- flushing of cache caused by refcounting, resorting to GC on reference cycles

Name: Anonymous 2014-03-31 21:58

>>2

not really, it includes the entire runtime, which is usually an interpreter, compiler, object dispatch system, garbage collector, and probably more.

You could undefine some of these things before distribution if you want, or write a tree shaker that undefines all unused symbols, but I'm not sure how much it would help.

ECL also creates fairly small binaries from what I hear.

The lisp way to distribute programs is have seperate applications all run under the same runtime, but that's not how things are typically done on unix.

Name: Anonymous 2014-04-01 8:10

When you distribute a .NET application you rely on an installed version of the distributed .NET runtime.

When you distribute a Java application you rely on an installed version of the distributed .NET runtime.

Please distribute your Lisp in source or FASL form and rely on the user having SBCL/CCL etc. installed. If they do not have it installed, please install it for them.

Please work with your Lisp implementation vendor to ensure there is an installer for that Lisp.

Please.

Name: Anonymous 2014-04-01 9:07

>>3
- cluttered code, segfaults and double frees[br]- flushing of cache caused by refcounting, resorting to GC on reference cycles
Rust has none of those

Name: Anonymous 2014-04-01 13:45

>>1
One thing I don't understand however is why executables require the full run-time?
Just because they can. MACLISP ran under 1 MB of memory...

http://en.wikipedia.org/wiki/Maclisp
http://en.wikipedia.org/wiki/PDP-10
The KA10 had a maximum main memory capacity (both virtual and physical) of 256 kilowords (equivalent to 1152 kilobytes).

Name: Anonymous 2014-04-01 13:46

>>2

You can use allocation pools, instead of GC.

Name: Anonymous 2014-04-01 13:51

>>6
Can Rust create/link libraries decently yet (at least dynamic)? I remember last time I looked into it they just threw a cutely-named crate system at me and said ``Pretend this isn't Java'' or something. They've got almost all the requirements to be a decent systems language, but for me to get on board the hype train I need to be able to link like C does it, or else be shown a damn good argument that Rust's way is as good or better.

NB because I'm off-topic now - a link to a relevant blog post from a developer or something would be more than enough for me.

Name: Anonymous 2014-04-01 14:05

>>3

Or you can write an AI, capable of analyzing the code statically and inserting calls to free(), where required.

Name: Anonymous 2014-04-01 14:07

>>10
The algorithm is already here!

We present a novel leak detection algorithm. To prove the absence of a memory leak, the algorithm assumes its presence and runs a backward heap analysis to disprove this assumption. We have implemented this approach in a memory leak analysis tool and used it to analyze several routines that manipulate linked lists and trees. Because of the reverse nature of the algorithm, the analysis can locally reason about the absence of memory leaks. We have also used the tool as a scalable, but unsound leak detector for C programs. The tool has found several bugs in larger programs from the SPEC2000 suite.

Name: Anonymous 2014-04-01 14:08

>>6
C-like syntax automatically falls under cluttered code. Rust a shit.

Name: Anonymous 2014-04-01 15:28

An example of a very fast, specialised memory management approach is the "per frame" allocator used in many games. This works by incrementing a single pointer to allocate memory, and at the end of a time period (typically a visual "frame") all objects are discarded at once by simply setting the pointer back to the base address and overwriting them in the next allocation. This can be "safe", however the constraints of object lifetime would be very strict.

Name: Anonymous 2014-04-01 15:31

>>13

I.e. vanilla Lisp could be used to implement AAA game, give you provide some interframe communication channels - i.e. make explicit, what data you want to move into the next frame.

Name: Anonymous 2014-04-01 18:42

>>14
Maybe turn based AAA-game. Real time game would be impossible due to GC pauses. Even turn based would be hell since you'd had to wait so long between turns. GC is shit.

Name: Anonymous 2014-04-01 19:31

>>15
[needs citation]

Name: Anonymous 2014-04-01 21:25

>>16
You just provided it. Thank you, >>16-san!

Name: Anonymous 2014-04-01 23:11

>>15
MMM is shit.

Name: Anonymous 2014-04-05 11:27

>>1
Lisp
GC is shit.

Name: Anonymous 2014-04-05 17:00

>>19
Please return to your thread.

Name: Anonymous 2014-04-05 17:02

What's all the fuss about big executables? Disk space is cheap, just delete one pron video and you'll never have to worry about large binaries.

Name: Anonymous 2014-04-05 17:20

What's all the fuss about fast executables? CPU time is cheap, just buy an Intel® i7® and you'll never have to worry about slow binaries.

Name: Anonymous 2014-04-05 20:43

>>21
What kind of plebian keeps porn videos in the root filesystem?

Name: Anonymous 2014-04-07 10:16

>>23
What kind of plebian partitions a HDD to billion partitions?

Name: Anonymous 2014-04-08 12:49

>>21
The executable must still be loaded into memory and transferred to the CPU. The most wasteful the binary, the more cache it uses, the more time is wasted on memory access.

Name: Anonymous 2014-04-09 16:49

>>25
Come fucking on, you'd have to tie your dick in knots to make executable code have a noticeable footprint on a modern machine's memory or cache. Data take up much more that code. I've never seen the size of a binary be a real performance concern.

Name: Anonymous 2014-04-09 21:30

>>26
Guess you've never been an embedded developer, then.

Name: Anonymous 2014-04-09 22:01

>>27
And before you ask, yes, this makes sense in the context of lisp. See http://zh.soup.io/post/122393574/Hedgehog-an-embedded-Lisp-in-20k or http://umlautllama.com/project.php?ShortName=Lithp or such.

Name: Anonymous 2015-05-09 17:46

>>19
Who are you quoting?

Name: Anonymous 2015-05-10 18:20

>>12
Rust doesn't have C-like syntax.

Name: Anonymous 2015-05-10 18:22

>>13
All of that is a crude ad hoc implementation of a generational GC. When will you Seppletards realize that your manual memory management boils down to reinventing (shittiest, error-prone and underperformant forms of) GC?

Name: Anonymous 2015-05-10 19:30

>>31
That's actually much faster, since there is no copying. But it only work under strict rules for lifetime. This is an example of why lower level languages are sometimes better. You have more control over these things, and can pick an implementation for a feature that works better, possibly with more restrictive assumptions of use, but with assumptions that hold. Higher level languages need to pick solutions that work under weaker assumptions.

Name: Anonymous 2015-05-11 0:53

>>25-san, have you not heard of demand-paged executables? The kernel maps executable sections lazily through generic mmap().

But still there's no excuse for a 400-kilobyte hello-world. Man up and stick the stdlib in a shared object you hippies, or you'll be in a Cabal-esque world of packaging hurt when those unmade decisions mount up over the years to finally rend you a constellation of new ones.

>>30
On the contrary: it's solidly a curly-brace language. The declaration syntax, match clauses, etc. come from ML and the like, but those don't do curly braces [except for Haskell (which gets it wrong)].
Don't change these.
Name: Email:
Entire Thread Thread List
All trademarks and copyrights on this site are owned by their respective parties. All comments and posts are the responsibility of their own posters.
- Tinychan + 2ch Mode + RSS -