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

best scheme/lisp for real time code

Name: Anonymous 2014-09-01 13:09

Is Chicken a good idea? I am worried about the way it does GC. Exhausting the stack seems a bit... Java. I'm looking at Gambit too but I don't know much about it yet.

Whatever I end up using needs to work on ARM. It doesn't have to target C as long as it has FFI and short GC pauses (I am aiming for less than 5ms.)

Name: Anonymous 2014-09-04 3:30

I often think about this, because I like Lisp but dislike GC.

You can get a "real time automatic memory management" of sorts in any language by never freeing anything, only allocating by bumping a pointer and relying on the OS to clean things up when the program exits.

From there, it's easy to have separate spaces for different purposes, and be able to independently reset each one to free up space. One example would be a common pattern in games, where one space is used for storing per-level data, and the other for per-frame data. Apache uses a similar approach, with one memory "pool" per request serviced. Another would be providing separate spaces for userspace threads. Obviously it's not truly automatic anymore because you have to think a bit about object lifetimes and whatnot, but at least you aren't calling malloc and free all the time or dealing with the drawbacks of mark-sweep or reference counting.

You could fairly easily integrate this into a Lispy language, either by explicitly passing an allocator to each function that allocates memory, or implicitly by setting an allocator per environment (but then things get hairy when you want to put short and long lived objects in different regions). In either case, purists would say it "isn't Lisp," but I think the result would be pretty usable if you were willing to bloat up code a bit and waste some memory for the sake of runtime simplicity.

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List