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