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