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 >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>
