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

Reply via email to