On Fri 11 Aug, Manuel M. T. Chakravarty wrote:
> Erlang applications are characterised as being soft-realtime
> applications:
>
> http://www.erlang.org/faq/x847.html#SOFT-REALTIME
>
> In one sentence, I would characterise this as ``it is fast
> enough most of the time.'' This seems to be good
On Fri 11 Aug, Byron Hale wrote:
> I don't mean that threads are non-deterministic, but that the execution
> time of a GC thread seems to be non-deterministic. Large collections need
> more time than small ones and the time required is some function of the
> store to be collected, is it not?
S
On Fri 11 Aug, Sengan wrote:
> I don't buy this: for a long time the embedded hard realtime people
> refused to use CPUs with cache because they would be
> "non-deterministic".
(I assume "non-deterministic" in this context means we can't determine the
execution time of a bit of code, even knowing
On Fri 11 Aug, George Russell wrote:
> However REALLY worst-time-bounded garbage collection is very expensive in
> CPU time. (Is there anything better than Baker's train algorithm?)
> In any case even if you do have garbage-collection, you will still need to
> demonstrate that you won't run out o
George Russell wrote:
> (Is there anything better than Baker's train algorithm?)
Sorry, I meant "treadmill" not "train". The train algorithm is an almost-bounded
garbage collection algorithm. (However it fails to be
properly bounded if you have large numbers of in-pointers to a node.)
Sengan wrote:
> I don't buy this: for a long time the embedded hard realtime people
> refused to use CPUs with cache because they would be
> "non-deterministic".
> They finally gave up, realizing that CPU's with caches are much faster.
> If garbage collection is relatively cheap and makes it 10x f
> On Fri 11 Aug, Byron Hale wrote:
> > Also, garbage collection is unlikely to satisfy any need
> > for automatic memory management in real-time systems for the foreseeable
> > future because an extra thread on a single processor is still
> > non-deterministic.
I don't buy this: for a long time t
Byron Hale <[EMAIL PROTECTED]> wrote,
> At 05:21 AM 8/11/2000 +0100, you wrote:
> >On Fri 11 Aug, Byron Hale wrote:
> > > Also, garbage collection is unlikely to satisfy any need
> > > for automatic memory management in real-time systems for the foreseeable
> > > future because an extra thread on
Adrian Hey <[EMAIL PROTECTED]> wrote,
> My objection to the use of GC (and by implication all current Haskell
> implementations) in embedded systems would be that if your program is
> sufficiently complex/powerful that it can't be implemented as some kind
> of _finite_ state machine, then it can
At 05:21 AM 8/11/2000 +0100, you wrote:
>On Fri 11 Aug, Byron Hale wrote:
> > Also, garbage collection is unlikely to satisfy any need
> > for automatic memory management in real-time systems for the foreseeable
> > future because an extra thread on a single processor is still
> > non-deterministi
On Fri 11 Aug, Byron Hale wrote:
> Also, garbage collection is unlikely to satisfy any need
> for automatic memory management in real-time systems for the foreseeable
> future because an extra thread on a single processor is still
> non-deterministic.
I'm not sure this is true, doesn't it depe
11 matches
Mail list logo
