Very nice! Is the time coming for a JuliaControl organization?
I am thinking of wrapping the ACADO toolkit: http://acado.github.io/ Regards: Uwe On Wednesday, March 23, 2016 at 3:40:43 PM UTC+1, Fredrik Bagge Carlson wrote: > > For those finding this page in search for a control systems toolbox: > The package ControlSystems.jl has seen extensive developement recently, > and developement is still ongoing > https://github.com/JuliaControl/ControlSystems.jl > > > On Wednesday, October 1, 2014 at 10:10:56 AM UTC+2, Uwe Fechner wrote: >> >> I created the following issue to track the progress on this: >> https://github.com/JuliaLang/julia/issues/8543 >> >> On Tuesday, September 30, 2014 3:29:01 PM UTC+2, Spencer Russell wrote: >>> >>> I'm looking forward to some sort of flag or option to turn on the >>> incremental GC, and trying to understand a bit more about the design space. >>> My naive thought process goes something like this: >>> >>> 1. The total time to collect garbage probably grows with number of >>> objects and total size to be freed (though maybe size doesn't matter >>> much >>> here?) >>> 2. An incremental GC will collect until it runs out of time, then >>> hand control back to the application until it's time to run again >>> 3. It seems like there's a rate of garbage generation where you're >>> building up garbage faster than the GC can collect it without missing >>> its >>> deadline >>> 4. It seems like if you stay below this rate you can consider your >>> maximum pause time to be bounded and memory won't be leaking. We hold >>> hands >>> and sing songs. >>> 5. So the issue is what to do when you're above that rate. Either >>> you: >>> 1. make sure memory consumption doesn't grow indefinitely by >>> having some heuristic for when the GC decides to give up on the >>> deadline, OR >>> 2. make sure the GC never violates its deadline and run the risk >>> of running out of memory >>> >>> Are there other options besides those two? >>> >>> I would definitely welcome an actual hard-realtime bounded-pause-time >>> GC, but it also seems valuable (and possibly more feasible) to have a GC >>> where the pause time is bounded with caveats and more careful programming. >>> I'm not sure whether this qualifies as *hard *realtime, though it seems >>> like it might if you can make those guarantees about your application code. >>> >>> It's also worth mentioning for other folks interested in latency that >>> that JIT compilation is a killer as well, so you need to guarantee that >>> you're pre-compiled all the possible methods that might get dispatched to. >>> >>> >>> peace, >>> s >>> >>> On Mon, Sep 29, 2014 at 4:25 PM, Stefan Karpinski <[email protected]> >>> wrote: >>> >>>> On Mon, Sep 29, 2014 at 4:21 PM, Uwe Fechner <[email protected]> >>>> wrote: >>>> >>>>> Jeff Bezanson suggested in the following discussion ( >>>>> https://github.com/JuliaLang/julia/pull/5227 ): >>>>> > It would be great to have the option to build with a low-pause GC >>>>> for users who might want that. >>>>> >>>>> This is exactly what I am looking for: To have two different garbage >>>>> collectors for Julia, a fast collector for non-real-time applications and >>>>> a >>>>> low-latency GC >>>>> for real-time applications. Uwe >>>>> >>>> >>>> Yeah, that would be great. >>>> >>> >>>
