+ 1<br><br><br>This is probably the biggest obstacle to using Haskell where I work. (Aviation industry, software for flight management systems for airplanes)<br><br>We often need to perform some computations with hard deadlines, say every 20ms, with very little jitter. <br>
Major GC&#39;s spoil the fun; It&#39;s quite easy to have a major GC take longer than 20ms, and currently they are not &quot;pauseable&quot; (nor is it trivial to make them so). <br><br>It would be very nice to have some annotation/DSL/compiler-flag that would let me run a small block of mostly regular haskell code under hard, real-time constraints.<br>
<br>Hmm, it looks like the HASP project is working on some of this, though I&#39;m not sure how portable their work is back to GHC: <a href="http://hasp.cs.pdx.edu/">http://hasp.cs.pdx.edu/</a><br><br>- Job<br><br><br><div class="gmail_quote">
On Wed, Aug 4, 2010 at 4:24 PM, Stephen Sinclair <span dir="ltr">&lt;<a href="mailto:radarsat1@gmail.com">radarsat1@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Aug 3, 8:31 pm, Jeremy Shaw &lt;<a href="mailto:jer...@n-heptane.com">jer...@n-heptane.com</a>&gt; wrote:<br>
&gt;  The only area I have had any trouble with Haskell is doing realtime<br>
&gt; music synthesis. And only because the garbage collector is not<br>
&gt; realtime friendly. That is not unfixable though. However, I am<br>
&gt; thinking that the best way to do realtime synthesis with Haskell is to<br>
&gt; use it to create a DSL that uses LLVM to create code at runtime so<br>
&gt; that the realtime code is outside the scope of the normal RTS and<br>
&gt; garbage collector.<br>
I&#39;m also very interested in this topic---how to apply a general-<br>
purpose functional language to real-time needs, even if it is in a<br>
domain-specific way.<br>
Indeed, it mostly comes down to memory management and the fact that<br>
functional concepts like closures and laziness require a lot of<br>
dynamic allocation and garbage collection.  Certainly, one solution is<br>
to provide a real-time-friendly memory manager.<br>
However, it&#39;s interesting to notice that, as proven by FAUST [1], a<br>
huge amount of DSP algorithms can be expressed functionally in a real-<br>
time-compatible way by describing them as static diagrams of connected<br>
blocks.  These can be efficiently compiled to imperative code with no<br>
dynamic memory allocation required.<br>
So yes, if such a language were available as an embedded DSL in<br>
Haskell (one effort can be found here [2]), it could be generated at<br>
run-time using LLVM and called out to.  Alternatively, it would be<br>
very cool if it were possible to generate code statically at compile<br>
time, just like in FAUST.  I can imagine this being very useful,<br>
especially if it could be generalized to operate on datatypes other<br>
than floating points, and had easy access to data structures provided<br>
by non-RT portions of the code.  If there are mutability requirements,<br>
it could be made to run in the ST monad with a pre-allocated<br>
Of course _modifying_ such structures at run-time is always a dynamic<br>
thing by definition, although there is the possibility of dynamically<br>
generating a replacement block diagram while an one existing one runs,<br>
and using an atomic pointer swap to switch them without causing<br>
In any case, as far as I know the only thing in the way is that it&#39;s<br>
impossible to tell GHC to compile a section of code in such as way as<br>
to guarantee avoidance of memory management.  Compilers and runtime-<br>
systems always seem to be either RT- or non-RT-friendly, but never<br>
seem to support the idea of code *portions* that have differing<br>
requirements.  My point is, RT code _can_ be expressed functionally,<br>
even if the RT-ness imposes certain expressivity restrictions.  It<br>
would be very cool to be able to mark sections of code as following<br>
such a &quot;sub-language&quot; and be guaranteed that the compiler will<br>
generate GC-free code for a particular function, if possible, or<br>
otherwise fail.<br>
Even if such a sub-language were no more expressive than C, it would<br>
be nice to be able to write it in Haskell instead of dropping down to<br>
C, so that data can be easily shared with non-RT parts, and Haskell&#39;s<br>
type checker could be exploited.  It seems strange to me that with<br>
technology like Haskell and GHC we still depend on using C to express<br>
these last remaining droplets of real-time determinism requirements---<br>
strange, since I think of higher-level languages like Haskell to be<br>
supersets of the capabilities of C---and annoying, because it means<br>
having to deal with the complexities of language interoperability,<br>
just for a few low-level components of an application.<br>
I realize some of this has probably been discussed in conjunction with<br>
FRP.  I&#39;m aware of one paper on RT-FRP that talks about requiring an<br>
RT-friendly sub-language [3], but I don&#39;t pretend to follow it<br>
completely.  I&#39;m almost sure it also has something to do with arrows,<br>
but I have very little idea what they are, since I&#39;m still just<br>
&quot;getting&quot; monads at this point in my personal Haskell understanding.<br>
I hope someone more knowledgeable about these things on this list<br>
might be able to comment on their relation to real-time determinism.<br>
[1] <a href="http://faust.grame.fr/" target="_blank">http://faust.grame.fr/</a><br>
[2] <a href="http://claudiusmaximus.goto10.org/cm/2009-12-04_heist_dataflow_algebra.html" target="_blank">http://claudiusmaximus.goto10.org/cm/2009-12-04_heist_dataflow_algebra.html</a><br>
[3] <a href="http://www.haskell.org/frp/rt-frp.pdf" target="_blank">http://www.haskell.org/frp/rt-frp.pdf</a><br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>