Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Carp: a statically typed lisp, without a GC, for high performance applications

github.com

Post reply on HN
Print view View original

31–40 of 71 posts

Re: Carp: a statically typed lisp, without a GC, for high performance applications

#31

Post by junke »

larsbrinkhoff wrote: post #27
junke wrote: post #5

Is there an explanation of the memory allocation used? There seem to be a GC ( https://github.com/eriksvedang/Carp/blob/master/src/gc.c ), maybe used in the compiler only, coupled with lifetime analysis ( https://github.com/eriksvedang/Carp/blob/8665a7f9a19d9347cc0... ), which as far as I know is used once ( https://github.com/eriksvedang/Carp/blob/6107e619d4f632acace... ) in the compiler. This analysis seems tied to…

As far as I understand from listening to Erik talk about Carp, there is an interactive interpreter which does use GC. In contrast, the compiler generates GC-free code.

Thanks. Is this talk online? I can't find it.

Re: Carp: a statically typed lisp, without a GC, for high performance applications

#32

Post by tom_mellior »

larsbrinkhoff wrote: post #27
junke wrote: post #5

Is there an explanation of the memory allocation used? There seem to be a GC ( https://github.com/eriksvedang/Carp/blob/master/src/gc.c ), maybe used in the compiler only, coupled with lifetime analysis ( https://github.com/eriksvedang/Carp/blob/8665a7f9a19d9347cc0... ), which as far as I know is used once ( https://github.com/eriksvedang/Carp/blob/6107e619d4f632acace... ) in the compiler. This analysis seems tied to…

As far as I understand from listening to Erik talk about Carp, there is an interactive interpreter which does use GC. In contrast, the compiler generates GC-free code.

> In contrast, the compiler generates GC-free code.

Yes, but the question was how it does that. Does it reject code where it cannot reliably detect lifetimes? Or does it generate code that just does not deallocate (i.e., that leaks) objects whose lifetime the compiler can't determine? Both of these are "GC-free"...

Re: Carp: a statically typed lisp, without a GC, for high performance applications

#33

Post by rurban »

tom_mellior wrote: post #32
larsbrinkhoff wrote: post #27

Earlier quoted context omitted.

As far as I understand from listening to Erik talk about Carp, there is an interactive interpreter which does use GC. In contrast, the compiler generates GC-free code.

> In contrast, the compiler generates GC-free code. Yes, but the question was how it does that. Does it reject code where it cannot reliably detect lifetimes? Or does it generate code that just does not deallocate (i.e., that leaks) objects whose lifetime the compiler can't determine? Both of these are "GC-free"...

Very simple. The compiler, written in lisp (with a GC) just generates C code, which is compiled and executed. Without any GC, it tracks the vars.

Re: Carp: a statically typed lisp, without a GC, for high performance applications

#34

Post by larsbrinkhoff »

junke wrote: post #31
larsbrinkhoff wrote: post #27

Earlier quoted context omitted.

As far as I understand from listening to Erik talk about Carp, there is an interactive interpreter which does use GC. In contrast, the compiler generates GC-free code.

Thanks. Is this talk online? I can't find it.

Sorry, it was not recorded.

Re: Carp: a statically typed lisp, without a GC, for high performance applications

#35

Post by larsbrinkhoff »

tom_mellior wrote: post #32
larsbrinkhoff wrote: post #27

Earlier quoted context omitted.

As far as I understand from listening to Erik talk about Carp, there is an interactive interpreter which does use GC. In contrast, the compiler generates GC-free code.

> In contrast, the compiler generates GC-free code. Yes, but the question was how it does that. Does it reject code where it cannot reliably detect lifetimes? Or does it generate code that just does not deallocate (i.e., that leaks) objects whose lifetime the compiler can't determine? Both of these are "GC-free"...

The compiler does lifetime analysis, and there is a "reference borrowing" concept like in Rust.

Re: Carp: a statically typed lisp, without a GC, for high performance applications

#36

Post by piokuc »

Pxtl wrote: post #2

That's brilliant... I'd always assumed lisps were so tightly bound to the GC that any other memory model was infeasible.

The idea of getting rid of GC is very exciting, as GC has a lot of drawbacks. I want to study Carp to see how this was achieved. Incidentally, today I also found Bone Lisp https://github.com/wolfgangj/bone-lisp/blob/master/README.md which has the same goal.

Re: Carp: a statically typed lisp, without a GC, for high performance applications

#37

Post by Pxtl »

eriksvedang wrote: post #14
akavel wrote: post #7

I understand this is marked as "a research project", so any answer here is possible and must be accepted; that said I'd really love to learn at least about plans with respect to the following questions: • Regarding FFI, is it possible to pass pointers to carp functions/closures as arguments to external dynamically loaded functions? are those features available in REPL? • What's the story/approach regarding structs in…

1. Yes, and yes! 2. No plans for inheritance at the moment, probably some kind of interfaces but that's not a top priority right now. Custom types are limited to structs, I will add union types soon 3. This has not been decided yet, I want to do more research before settling on any particular solution. It will be a high priority though, since I want to use it for the games I write Thanks, Erik

Is the plan for this to be a stand-alone gaming language or a language for embedding into a gaming engine or framework like Lua? Obviously built-in threading constructs are less essential for the latter.

Re: Carp: a statically typed lisp, without a GC, for high performance applications

#38

Post by lispm »

Pxtl wrote: post #2

That's brilliant... I'd always assumed lisps were so tightly bound to the GC that any other memory model was infeasible.

https://github.com/vsedach/Thinlisp-1.1

  ThinLisp is not a typical Lisp implementation in that it does not implement a
  garbage collector or many of the other run-time development features of other
  Lisps.  ThinLisp is designed for producing high quality deliverable C libraries
  and executables from Lisp sources.  Originally designed for real-time control
  applications, ThinLisp stresses run-time performance at the expense of some
  development time conveniences.
Prescheme

  http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.3.4031
Schlep

  http://people.csail.mit.edu/jaffer/Schlep/scm2c.html
BitC

  http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.570.5677&rep=rep1&type=pdf
and various others...

Re: Carp: a statically typed lisp, without a GC, for high performance applications

#39

Post by jlarocco »

I saw this a month or two ago and submitted a pull request that I still need to fix up to have it accepted. My original intention was to benchmark a bit against SBCL, but I got sidetracked with the pull request, then lost time and then forgot about it. I need to get back to it and see about getting it submitted.

Anyway, it sounds neat, but even after playing with it a bit, I'm not sure how necessary it is.

SBCL (and supposedly the commercial Common Lisps) are pretty fast nowadays. Not C fast, but I can usually get about 1/2 - 1/3 C speed and 4-8x faster than Python without doing anything special.

For example, I made an animation app (https://github.com/jl2/qt-fft-viz) that reads an MP3 and generates an animation while it plays back, and I get 90+ fps. It's not a big graphics/CPU intense video game, but it's doing a lot of FFT calculations and some basic graphics.

So, not to diminish the Carp project, but I think regular old Common Lisp is faster than most people think, is better supported, has more libraries, and works on more platforms and operating systems.

Re: Carp: a statically typed lisp, without a GC, for high performance applications

#40

Post by PDoyle »

rurban wrote: post #33
tom_mellior wrote: post #32

Earlier quoted context omitted.

> In contrast, the compiler generates GC-free code. Yes, but the question was how it does that. Does it reject code where it cannot reliably detect lifetimes? Or does it generate code that just does not deallocate (i.e., that leaks) objects whose lifetime the compiler can't determine? Both of these are "GC-free"...

Very simple. The compiler, written in lisp (with a GC) just generates C code, which is compiled and executed. Without any GC, it tracks the vars.

No, not simple. Analyzing an arbitrary lisp program to determine the lifetimes of all allocated structures reduces to the halting problem, so it's undecidable. You must either restrict the input program or tolerate some leaks.
Post reply on HN