3 ms·

Guy says he made an audio engine, graphics engine, game engine, and so on. In order for these to be useful for a serious, high-quality product, there must be n

Guy says he made an audio engine, graphics engine, game engine, and so on. In order for these to be useful for a serious, high-quality product, there must be no perceptible pauses induced by garbage collection. An audio engine in particular seems to need to run extremely quickly--on Mac OS X, at any rate. Perform this experiment: Pick your favorite music player, such as iTunes, play your favorite song, and run this: $ for ((;;)); do killall -STOP iTunes; sleep .008; killall -CONT iTunes; sleep .050; done This simulates 8-millisecond GC pauses. On my fairly fast, modern laptop, this is too much--I hear a bunch of stuttering in the audio. (It's kind of surreal.) I have to cut the pauses down to 5 milliseconds to completely avoid stuttering. This goes for every program that produces audio output that I've tested. It is possible that audio output under other operating systems is handled differently, and that you could install a buffer of sound output for the next 50 or 100 milliseconds or whatever [it may even be possible to do that on OS X--I don't know], but I'm not betting on it. ... Besides audio, usually games want to maintain a certain refresh rate, such as 30 or 60 frames per second. 30 fps is 33 milliseconds per frame. If a pause lasts any longer (in fact, if the pause lasts [33 msec - <time to compute and draw the next frame>]), the drawing will stutter. Maybe you might think, "Eh, who cares? It's just a little stutter from time to time." If I've read this guy right, this is exactly the sort of thing he would not tolerate. In order for such an audio library to be writable in Common Lisp, Common Lisp compilers/runtime systems will have to get their act together and ensure that the maximum GC pause time is less than 5 milliseconds on my machine, no matter how many objects are allocated by the program using the library. In the absence of Common Lisp compilers/runtimes that can do this, there are two choices: write it in a different language, such as C or C++ with manual memory management; or write your own Common Lisp runtime + compiler that can. I have gone down the latter rabbit hole. You may hear if I come out at some point.

meric 14y ago
You could write bindings for libraries he's wrote and write higher level logic in CL. It also appears (from google searches) there are ways to tweak garbage collectors in some versions of Lisp as well as ways to manually manage some memory? I don't know if they can be applied to writing audio or graphics libraries though. I've ran your script. Was surprised lower milliseconds I wasn't able to notice the stutter. I'd have thought even 1 ms would be noticeable. >> Common Lisp runtime + compiler Would like to hear more about this. Have you written about it in a blog post somewhere? One more point: Common lisp isn't the only option. There are other powerful functional languages out there. e.g. Ocaml which uses an incremental GC.
jes5199 14y ago
How about a C process that only manages audio, which takes instructions over a socket from your Lisp program of what audio to play? You could even stream stuttering audio from Lisp into a user-space buffer written in C that smooths it out.
javajosh 14y ago
This is really ambitious, and fascinating for someone who (like me) has really never done anything serious in an environment that wasn't garbage collected. It brings up a fundamental question: what does it mean to release memory? How long does it take to release memory? I assume that it involves sending some sort of signal to the surrounding environment. Either that or your program gets two "special" values that it uses to tag memory regions, and the OS periodically truncates (or adds to) your image when those tags reach certain thresholds. If it's explicit, and a C function call that takes something like a memory address range as an argument what does the kernel do at that point?

meric 14y ago

You could write bindings for libraries he's wrote and write higher level logic in CL. It also appears (from google searches) there are ways to tweak garbage collectors in some versions of Lisp as well as ways to manually manage some memory? I don't know if they can be applied to writing audio or graphics libraries though. I've ran your script. Was surprised lower milliseconds I wasn't able to notice the stutter. I'd have thought even 1 ms would be noticeable. >> Common Lisp runtime + compiler Would like to hear more about this. Have you written about it in a blog post somewhere? One more point: Common lisp isn't the only option. There are other powerful functional languages out there. e.g. Ocaml which uses an incremental GC.

jes5199 14y ago

How about a C process that only manages audio, which takes instructions over a socket from your Lisp program of what audio to play? You could even stream stuttering audio from Lisp into a user-space buffer written in C that smooths it out.

javajosh 14y ago

This is really ambitious, and fascinating for someone who (like me) has really never done anything serious in an environment that wasn't garbage collected. It brings up a fundamental question: what does it mean to release memory? How long does it take to release memory? I assume that it involves sending some sort of signal to the surrounding environment. Either that or your program gets two "special" values that it uses to tag memory regions, and the OS periodically truncates (or adds to) your image when those tags reach certain thresholds. If it's explicit, and a C function call that takes something like a memory address range as an argument what does the kernel do at that point?