From: Faré <fa...@gm...> - 2013-07-01 14:16:23
|
You can use tmpfs not to hit the disk. But yes, being able to load a fasl from stream would be nice. As for avoiding GC, unwanted compile-time side-effects, etc., you might want to (pre)fork your compilation server after loading your common core. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. On Mon, Jul 1, 2013 at 6:41 AM, Tito Latini <tit...@gm...> wrote: > Hi, > > I'm writing a music/dsp programming environment in Common Lisp called > Incudine (http://incudine.sourceforge.net). Currently it works only > with SBCL and the performance is really good. Thank you for the magic! > > Incudine uses different memory pools and the format for the sample is > DOUBLE-FLOAT by default, unboxed type on the C heap (an example of the > expansion of DEFSYNTH is here: http://incudine.sf.net/tutorial_04.html). > Therefore there is not garbage during the synthesis in realtime of a > well definited synth. However there is an inevitable noise if a synth > is compiled while something is playing in realtime. > > I'm thinking about the possibility to use two instances of SBCL, one > dedicated to the compilation: > > - SBCL-A sends to SBCL-B all the stuff to compile > (with a possible cons-pool) > The priority of SBCL-B is lower than SBCL-A. > > - SBCL-A loads the fasl (without to use the disk if possible) > compiled by SBCL-B (is it considerable for gc?). The latency > for non-synthdef things is probably not big. > > - All the standard-output is redirected to SBCL-B > > Besides, two instances of SBCL require a thorough distribution of the > resources. To complicate the code is not my preferred sport but the > end justifies the means. However, the possibility to stop-the-world is > lower but yet possible. > > The alternative is to use another implementation of CL when the > performance is not so important. To use more cores for the synthesis > could help in this direction. > > I would like to know your advice about this problem. > > Tito Latini > > PS: about 1.1.9, tested 1656e54 without problems on x86_64 > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel > |