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