Jeff Bezanson suggested in the following discussion ( https://github.com/JuliaLang/julia/pull/5227 ): > It would be great to have the option to build with a low-pause GC for users who might want that.
This is exactly what I am looking for: To have two different garbage collectors for Julia, a fast collector for non-real-time applications and a low-latency GC for real-time applications. Uwe On Monday, September 29, 2014 7:50:34 PM UTC+2, Simon Kornblith wrote: > > A collector with a hard constraint on the worst-case GC time is a hard > real-time collector. I don't think many collectors can guarantee 2-4 ms > worst case GC times (although evidently Staccato can). There is also a > tradeoff between having a real-time collector and having the fastest > possible collector for non-real-time applications that has been discussed > elsewhere. > > Simon > > On Monday, September 29, 2014 1:37:13 PM UTC-4, Uwe Fechner wrote: >> >> For me it would be important to reach the real-time performance of >> Python/ Numba with Julia: >> >> I would like to port my flight simulator ( >> https://bitbucket.org/ufechner/freekitesim) to Julia, >> to improve the performance, make maintenance easier and to start working >> with automated >> differentiation. >> >> I think this performance (max. 2-4 ms time for a call of an incremental >> garbage collector) should >> be possible to achieve by implementing an improved garbage collector for >> Julia. >> >> This would not be hard real-time, but already very useful for many >> practical applications. >> >> Uwe >> >> >> On Monday, September 29, 2014 4:03:43 PM UTC+2, Simon Kornblith wrote: >>> >>> Manually managing memory is far easier than implementing a hard >>> real-time garbage collector, but hard real-time garbage collectors do >>> exist: the Staccato paper >>> <http://researcher.watson.ibm.com/researcher/files/us-groved/rc24504.pdf> >>> claims worst-case pause times of under 1 ms. >>> >>> Simon >>> >>> On Monday, September 29, 2014 4:55:41 AM UTC-4, Steven Sagaert wrote: >>>> >>>> Hi Uwe, >>>> In the Java world, Azul Zing is something along the lines of the first >>>> ref but I think it is still only soft real time. If you want that kind of >>>> garantees it's probably better not to keep garbage lying around to be >>>> collected later but free the memory immediately when no longer needed like >>>> via smart pointers as in C++. In fact that gives you almost everything a >>>> GC >>>> does except for collecting cycles but circular datastructures are rare and >>>> you can always break the cycles yourself so this isn't a big deal in >>>> practice. >>>> >>>> On Sunday, September 28, 2014 9:10:39 PM UTC+2, Uwe Fechner wrote: >>>>> >>>>> Event though pre-allocation is preferred for real-time >>>>> application, often there are some parts of the code >>>>> that are hard to implement without any garbage >>>>> collection. >>>>> >>>>> Hard real-time is possible even if you are using a garbage >>>>> collector. >>>>> >>>>> Some references for this point of view: >>>>> >>>>> http://michaelrbernste.in/2013/06/03/real-time-garbage-collection-is-real.html >>>>> >>>>> https://lwn.net/images/conf/rtlws-2011/proc/Klotzbuecher.pdf >>>>> >>>>> Best regards: >>>>> >>>>> Uwe Fechner >>>>> >>>>> On Sunday, September 28, 2014 4:53:48 PM UTC+2, Steven Sagaert wrote: >>>>>> >>>>>> GC will always be non-deterministic. For "hard" real time you just >>>>>> need to manage memory yourself. That's the approach used by real time >>>>>> Java >>>>>> http://www.rtsj.org/ >>>>>> >>>>>> On Monday, September 15, 2014 10:25:07 AM UTC+2, Uwe Fechner wrote: >>>>>>> >>>>>>> Hi, >>>>>>> I am working an airborne wind energy as well. I wrote a kite-power >>>>>>> system simulator in Python, where also one of the controllers (the >>>>>>> winch >>>>>>> controller) is >>>>>>> implemented in Python. ( https://bitbucket.org/ufechner/freekitesim >>>>>>> ) >>>>>>> >>>>>>> With Python you can reach a jitter of less than 2 ms in the 20Hz >>>>>>> control loop quite easily (on low-latency Linux). In my case this is >>>>>>> sufficient for prototyping, >>>>>>> but the real flight control system should run at a higher update >>>>>>> frequency (perhaps 200 Hz). >>>>>>> >>>>>>> In contrast to Julia Python is using reference counting, and in my >>>>>>> Python applications I just turn off the garbage collection. >>>>>>> >>>>>>> For Julia (and I would love to rewrite the simulator in Julia) this >>>>>>> is probably not an option. A better garbage collector >>>>>>> (which is in the pipeline, see: >>>>>>> https://github.com/JuliaLang/julia/pull/5227 ) would definitely >>>>>>> help. >>>>>>> >>>>>>> Generating embedded controllers in LLVM IR would be great! >>>>>>> >>>>>>> Best regards: >>>>>>> >>>>>>> Uwe >>>>>>> >>>>>>> On Monday, September 15, 2014 8:32:02 AM UTC+2, Andrew Wagner wrote: >>>>>>>> >>>>>>>> Hi Spencer! >>>>>>>> >>>>>>>> My job in airborne wind energy is ending soon so I don't have a >>>>>>>> specific application (aside from control), but I would want to stay >>>>>>>> sub-ms >>>>>>>> for anything in-process. I have been using Orocos extensively for the >>>>>>>> last >>>>>>>> few years. It's the best control middleware in the open source world, >>>>>>>> but >>>>>>>> I think a lot of things could be improved if it was re-implemented in >>>>>>>> a >>>>>>>> language with a better typesystem and introspection... one example >>>>>>>> would be >>>>>>>> that adding a new type to the system requires quite a bit of >>>>>>>> boilerplate >>>>>>>> code, creating an incentive for users to just pass data in flat >>>>>>>> arrays, >>>>>>>> subverting type safety. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Andrew >>>>>>>> >>>>>>>> On Mon, Sep 15, 2014 at 7:03 AM, Spencer Russell < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> Hi Andrew, >>>>>>>>> >>>>>>>>> What are your realtime deadlines? I'm working on live audio >>>>>>>>> processing stuff with Julia, where I'd like to get the audio latency >>>>>>>>> down >>>>>>>>> into a few ms. Julia definitely isn't there yet (and might never get >>>>>>>>> true >>>>>>>>> hard-realtime), but there's some promising work being done on the GC >>>>>>>>> to >>>>>>>>> reduce pause time for lower-latency applications. It's also helpful >>>>>>>>> to >>>>>>>>> profile the code to reduce allocations (and the need for GC) down to >>>>>>>>> a >>>>>>>>> minimum. I haven't yet gotten down to zero-allocation code in my >>>>>>>>> render >>>>>>>>> loop, but once I got it down below 100 bytes I moved on to other more >>>>>>>>> pressing features. At some point I'll dig deeper to see if I can get >>>>>>>>> rid of >>>>>>>>> the last few allocations. >>>>>>>>> >>>>>>>>> I'd definitely be happy if there are some more folks out there >>>>>>>>> driving demand for lower-latency Julia. :) >>>>>>>>> >>>>>>>>> peace, >>>>>>>>> s >>>>>>>>> >>>>>>>>> On Sun, Sep 14, 2014 at 3:58 PM, Andrew Wagner <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Hello again Uwe! >>>>>>>>>> >>>>>>>>>> It's fun running into someone I know on a language geek forum :) >>>>>>>>>> I'm helping one of our bachelor's students implement an LQR >>>>>>>>>> controller on >>>>>>>>>> our carousel in Freiburg. It's an ugly hack, but I'm calling an >>>>>>>>>> octave >>>>>>>>>> script to recompute the feedback gains online. Octave wraps slicot, >>>>>>>>>> so if >>>>>>>>>> the licenses are compatible, perhaps wrapping slicot is the way to >>>>>>>>>> go for >>>>>>>>>> some functions, if the licenses are compatible. >>>>>>>>>> >>>>>>>>>> Personally, I have a burning desire for a better language we can >>>>>>>>>> actually do control in (rust?). I doubt Julia qualifies due to the >>>>>>>>>> garbage >>>>>>>>>> collection, but does anyone know if Julia has some sort of way to >>>>>>>>>> JIT Julia >>>>>>>>>> expressions to code that does ~not have any garbage collection? If >>>>>>>>>> so, is >>>>>>>>>> there a way to export them as object files and link against them >>>>>>>>>> from C? >>>>>>>>>> Then you'd still have to write glue code in a systems language, but >>>>>>>>>> at >>>>>>>>>> least the implementation of the controller wouldn't have to cross a >>>>>>>>>> language boundary... >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> Andrew >>>>>>>>>> >>>>>>>>>> On Thursday, February 20, 2014 10:56:20 PM UTC+1, Uwe Fechner >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> I could not find any control system library for Julia yet. Would >>>>>>>>>>> that make sense? >>>>>>>>>>> There is a control system library available for Python: >>>>>>>>>>> http://www.cds.caltech.edu/~murray/wiki/index.php/Python-control >>>>>>>>>>> >>>>>>>>>>> Perhaps this could be used as starting point? I think that >>>>>>>>>>> implementing this in Julia >>>>>>>>>>> should be easier and faster than in Python. >>>>>>>>>>> >>>>>>>>>>> Any comments? >>>>>>>>>>> Should I open a feature request? >>>>>>>>>>> >>>>>>>>>>> Uwe Fechner, TU Delft, The Netherlands >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>
