Mike Meyer | 27 Nov 20:40 2012

Real-time code in Haskell (Was: Can a GC delay TCP connection formation?)

On Tue, Nov 27, 2012 at 3:45 AM, Gregory Collins
<greg <at> gregorycollins.net> wrote:
> If you have a hard real-time requirement then a garbage-collected
> language may not be appropriate for you.

This is a common meme, but frankly, it isn't true. When writing
real-time code, you just need to make sure that everything that
happens takes a known maximum amount of time. Then, you can sum up the
maximums and verify that you do indeed finish in the real-time window
of the task.

GC is a problem because it's not predictable, and may not have a
maximum. However, it's no worse than a modern version of the C
function malloc. Some of those even do garbage collection internally
before doing an OS call if they're out of memory. The solution is the
same in both cases - make sure you don't do GC (or call malloc) in the
critical region. Both require knowing implementation details of
everything you call, but it isn't impossible, or even particularly
difficult.

Lazyness, on the other hand ... I haven't thought about. I suspect you
need to force the evaluation of everything you're going to need before
you start the critical region, but I wonder if that's enough? Has
anyone out there investigated this?

       Thanks,
       <mike
timothyhobbs | 27 Nov 20:52 2012
Picon

Re: Real-time code in Haskell (Was: Can a GC delay TCP connection formation?)

What triggers GC in haskell?  We obviously aren't using Java's method of GC as needed(for good reasons, Java's method is terrible because you get slow downs when you need speed the most).  But we should be able to learn something from Java and have a gc::IO() method that one could call BEFORE a critical region of code...


---------- Původní zpráva ----------
Od: Mike Meyer <mwm <at> mired.org>
Datum: 27. 11. 2012
Předmět: [Haskell-cafe] Real-time code in Haskell (Was: Can a GC delay TCP connection formation?)

On Tue, Nov 27, 2012 at 3:45 AM, Gregory Collins
<greg <at> gregorycollins.net> wrote:
> If you have a hard real-time requirement then a garbage-collected
> language may not be appropriate for you.

This is a common meme, but frankly, it isn't true. When writing
real-time code, you just need to make sure that everything that
happens takes a known maximum amount of time. Then, you can sum up the
maximums and verify that you do indeed finish in the real-time window
of the task.

GC is a problem because it's not predictable, and may not have a
maximum. However, it's no worse than a modern version of the C
function malloc. Some of those even do garbage collection internally
before doing an OS call if they're out of memory. The solution is the
same in both cases - make sure you don't do GC (or call malloc) in the
critical region. Both require knowing implementation details of
everything you call, but it isn't impossible, or even particularly
difficult.

Lazyness, on the other hand ... I haven't thought about. I suspect you
need to force the evaluation of everything you're going to need before
you start the critical region, but I wonder if that's enough? Has
anyone out there investigated this?

Thanks,
<mike

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Felipe Almeida Lessa | 27 Nov 20:59 2012
Picon

Re: Real-time code in Haskell (Was: Can a GC delay TCP connection formation?)

http://hackage.haskell.org/packages/archive/base/4.6.0.0/doc/html/System-Mem.html#v:performGC

On Tue, Nov 27, 2012 at 5:52 PM,  <timothyhobbs <at> seznam.cz> wrote:
> What triggers GC in haskell?  We obviously aren't using Java's method of GC
> as needed(for good reasons, Java's method is terrible because you get slow
> downs when you need speed the most).  But we should be able to learn
> something from Java and have a gc::IO() method that one could call BEFORE a
> critical region of code...
>
>
> ---------- Původní zpráva ----------
> Od: Mike Meyer <mwm <at> mired.org>
> Datum: 27. 11. 2012
> Předmět: [Haskell-cafe] Real-time code in Haskell (Was: Can a GC delay TCP
> connection formation?)
>
> On Tue, Nov 27, 2012 at 3:45 AM, Gregory Collins
> <greg <at> gregorycollins.net> wrote:
>> If you have a hard real-time requirement then a garbage-collected
>> language may not be appropriate for you.
>
> This is a common meme, but frankly, it isn't true. When writing
> real-time code, you just need to make sure that everything that
> happens takes a known maximum amount of time. Then, you can sum up the
> maximums and verify that you do indeed finish in the real-time window
> of the task.
>
> GC is a problem because it's not predictable, and may not have a
> maximum. However, it's no worse than a modern version of the C
> function malloc. Some of those even do garbage collection internally
> before doing an OS call if they're out of memory. The solution is the
> same in both cases - make sure you don't do GC (or call malloc) in the
> critical region. Both require knowing implementation details of
> everything you call, but it isn't impossible, or even particularly
> difficult.
>
> Lazyness, on the other hand ... I haven't thought about. I suspect you
> need to force the evaluation of everything you're going to need before
> you start the critical region, but I wonder if that's enough? Has
> anyone out there investigated this?
>
> Thanks,
> <mike
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

--

-- 
Felipe.

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Roman Cheplyaka | 27 Nov 21:18 2012

Re: Real-time code in Haskell (Was: Can a GC delay TCP connection formation?)

* Mike Meyer <mwm <at> mired.org> [2012-11-27 13:40:17-0600]
> Lazyness, on the other hand ... I haven't thought about. I suspect you
> need to force the evaluation of everything you're going to need before
> you start the critical region, but I wonder if that's enough? Has
> anyone out there investigated this?

I don't know much about RT systems, but if GC is not a problem, then
laziness should be even less so. It is much more predictable, especially
when you look at the Core.

Roman

Gmane