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