Re: [Haskell-cafe] real-time audio processing [Was: can Haskell do everyting as we want?]
It's not an EDSL (though I'm a huge fan of the concept) because we wan't to pitch the language to programmers who currently use C/Ada. As much as I love EDSL's, they are particularly hard to sell to entrenched engineers without substantial effort or mandate. Dangling a few neat features on top of a comfortable tool set hopefully will stimulate some curiosity and help sell Haskell/EDSL's in the future... On Fri, Aug 6, 2010 at 11:34 AM, C K Kashyap wrote: > Hey John, > The language you are working on - is it a EDSL in Haskell? If not, had you > considered such an option? > > On Thu, Aug 5, 2010 at 8:11 PM, Job Vranish wrote: > >> Yeah Atom is pretty slick, though unfortunately it's not quite powerful >> enough for much of the stuff that we do. >> >> John Van Enk and I are actually working on a language that's similar to C >> (and compiles to C), but has polymorphism, type inference and other goodies. >> The goal is to make working on embedded systems a bit less painful, while >> still being able to do anything that C can do (like run on an 8 bit micro). >> Hopfully, if things go as planned, we'll have a working beta out by the >> end of the month :) >> >> - Job >> >> >> On Wed, Aug 4, 2010 at 5:58 PM, Don Stewart wrote: >> >>> job.vranish: >>> > + 1 >>> > >>> > >>> > This is probably the biggest obstacle to using Haskell where I work. >>> (Aviation >>> > industry, software for flight management systems for airplanes) >>> > >>> > We often need to perform some computations with hard deadlines, say >>> every 20ms, >>> > with very little jitter. >>> > Major GC's spoil the fun; It's quite easy to have a major GC take >>> longer than >>> > 20ms, and currently they are not "pauseable" (nor is it trivial to make >>> them >>> > so). >>> > >>> > 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. >>> > >>> > Hmm, it looks like the HASP project is working on some of this, though >>> I'm not >>> > sure how portable their work is back to GHC: http://hasp.cs.pdx.edu/ >>> > >>> >>> Or look at EDSLs, like Atom: >>> >>>http://hackage.haskell.org/package/atom >>> >> >> >> ___ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > > > -- > Regards, > Kashyap > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] real-time audio processing [Was: can Haskell do everyting as we want?]
Hey John, The language you are working on - is it a EDSL in Haskell? If not, had you considered such an option? On Thu, Aug 5, 2010 at 8:11 PM, Job Vranish wrote: > Yeah Atom is pretty slick, though unfortunately it's not quite powerful > enough for much of the stuff that we do. > > John Van Enk and I are actually working on a language that's similar to C > (and compiles to C), but has polymorphism, type inference and other goodies. > The goal is to make working on embedded systems a bit less painful, while > still being able to do anything that C can do (like run on an 8 bit micro). > Hopfully, if things go as planned, we'll have a working beta out by the end > of the month :) > > - Job > > > On Wed, Aug 4, 2010 at 5:58 PM, Don Stewart wrote: > >> job.vranish: >> > + 1 >> > >> > >> > This is probably the biggest obstacle to using Haskell where I work. >> (Aviation >> > industry, software for flight management systems for airplanes) >> > >> > We often need to perform some computations with hard deadlines, say >> every 20ms, >> > with very little jitter. >> > Major GC's spoil the fun; It's quite easy to have a major GC take longer >> than >> > 20ms, and currently they are not "pauseable" (nor is it trivial to make >> them >> > so). >> > >> > 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. >> > >> > Hmm, it looks like the HASP project is working on some of this, though >> I'm not >> > sure how portable their work is back to GHC: http://hasp.cs.pdx.edu/ >> > >> >> Or look at EDSLs, like Atom: >> >>http://hackage.haskell.org/package/atom >> > > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- Regards, Kashyap ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] real-time audio processing [Was: can Haskell do everyting as we want?]
On 5 August 2010 15:41, Job Vranish wrote: > John Van Enk and I are actually working on a language that's similar to C > (and compiles to C), but has polymorphism, type inference and other goodies. I guess you have seen BitC (http://www.bitc-lang.org/)? It has the performance of C but also type inference, polymorphism, type classes, first class functions... I've never used it but have heard nice things. Cheers, Max ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] real-time audio processing [Was: can Haskell do everyting as we want?]
Yeah Atom is pretty slick, though unfortunately it's not quite powerful enough for much of the stuff that we do. John Van Enk and I are actually working on a language that's similar to C (and compiles to C), but has polymorphism, type inference and other goodies. The goal is to make working on embedded systems a bit less painful, while still being able to do anything that C can do (like run on an 8 bit micro). Hopfully, if things go as planned, we'll have a working beta out by the end of the month :) - Job On Wed, Aug 4, 2010 at 5:58 PM, Don Stewart wrote: > job.vranish: > > + 1 > > > > > > This is probably the biggest obstacle to using Haskell where I work. > (Aviation > > industry, software for flight management systems for airplanes) > > > > We often need to perform some computations with hard deadlines, say every > 20ms, > > with very little jitter. > > Major GC's spoil the fun; It's quite easy to have a major GC take longer > than > > 20ms, and currently they are not "pauseable" (nor is it trivial to make > them > > so). > > > > 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. > > > > Hmm, it looks like the HASP project is working on some of this, though > I'm not > > sure how portable their work is back to GHC: http://hasp.cs.pdx.edu/ > > > > Or look at EDSLs, like Atom: > >http://hackage.haskell.org/package/atom > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] real-time audio processing [Was: can Haskell do everyting as we want?]
job.vranish: > + 1 > > > This is probably the biggest obstacle to using Haskell where I work. (Aviation > industry, software for flight management systems for airplanes) > > We often need to perform some computations with hard deadlines, say every > 20ms, > with very little jitter. > Major GC's spoil the fun; It's quite easy to have a major GC take longer than > 20ms, and currently they are not "pauseable" (nor is it trivial to make them > so). > > 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. > > Hmm, it looks like the HASP project is working on some of this, though I'm not > sure how portable their work is back to GHC: http://hasp.cs.pdx.edu/ > Or look at EDSLs, like Atom: http://hackage.haskell.org/package/atom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] real-time audio processing [Was: can Haskell do everyting as we want?]
+ 1 This is probably the biggest obstacle to using Haskell where I work. (Aviation industry, software for flight management systems for airplanes) We often need to perform some computations with hard deadlines, say every 20ms, with very little jitter. Major GC's spoil the fun; It's quite easy to have a major GC take longer than 20ms, and currently they are not "pauseable" (nor is it trivial to make them so). 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. Hmm, it looks like the HASP project is working on some of this, though I'm not sure how portable their work is back to GHC: http://hasp.cs.pdx.edu/ - Job On Wed, Aug 4, 2010 at 4:24 PM, Stephen Sinclair wrote: > On Aug 3, 8:31 pm, Jeremy Shaw wrote: > > The only area I have had any trouble with Haskell is doing realtime > > music synthesis. And only because the garbage collector is not > > realtime friendly. That is not unfixable though. However, I am > > thinking that the best way to do realtime synthesis with Haskell is to > > use it to create a DSL that uses LLVM to create code at runtime so > > that the realtime code is outside the scope of the normal RTS and > > garbage collector. > > I'm also very interested in this topic---how to apply a general- > purpose functional language to real-time needs, even if it is in a > domain-specific way. > > Indeed, it mostly comes down to memory management and the fact that > functional concepts like closures and laziness require a lot of > dynamic allocation and garbage collection. Certainly, one solution is > to provide a real-time-friendly memory manager. > > However, it's interesting to notice that, as proven by FAUST [1], a > huge amount of DSP algorithms can be expressed functionally in a real- > time-compatible way by describing them as static diagrams of connected > blocks. These can be efficiently compiled to imperative code with no > dynamic memory allocation required. > > So yes, if such a language were available as an embedded DSL in > Haskell (one effort can be found here [2]), it could be generated at > run-time using LLVM and called out to. Alternatively, it would be > very cool if it were possible to generate code statically at compile > time, just like in FAUST. I can imagine this being very useful, > especially if it could be generalized to operate on datatypes other > than floating points, and had easy access to data structures provided > by non-RT portions of the code. If there are mutability requirements, > it could be made to run in the ST monad with a pre-allocated > workspace. > > Of course _modifying_ such structures at run-time is always a dynamic > thing by definition, although there is the possibility of dynamically > generating a replacement block diagram while an one existing one runs, > and using an atomic pointer swap to switch them without causing > interruptions. > > In any case, as far as I know the only thing in the way is that it's > impossible to tell GHC to compile a section of code in such as way as > to guarantee avoidance of memory management. Compilers and runtime- > systems always seem to be either RT- or non-RT-friendly, but never > seem to support the idea of code *portions* that have differing > requirements. My point is, RT code _can_ be expressed functionally, > even if the RT-ness imposes certain expressivity restrictions. It > would be very cool to be able to mark sections of code as following > such a "sub-language" and be guaranteed that the compiler will > generate GC-free code for a particular function, if possible, or > otherwise fail. > > Even if such a sub-language were no more expressive than C, it would > be nice to be able to write it in Haskell instead of dropping down to > C, so that data can be easily shared with non-RT parts, and Haskell's > type checker could be exploited. It seems strange to me that with > technology like Haskell and GHC we still depend on using C to express > these last remaining droplets of real-time determinism requirements--- > strange, since I think of higher-level languages like Haskell to be > supersets of the capabilities of C---and annoying, because it means > having to deal with the complexities of language interoperability, > just for a few low-level components of an application. > > I realize some of this has probably been discussed in conjunction with > FRP. I'm aware of one paper on RT-FRP that talks about requiring an > RT-friendly sub-language [3], but I don't pretend to follow it > completely. I'm almost sure it also has something to do with arrows, > but I have very little idea what they are, since I'm still just > "getting" monads at this point in my personal Haskell understanding. > I hope someone more knowledgeable about these things on this list > might be able to comment on their relation to real-time determinism. > > [1] http://faust.grame.fr/ > [2] > http://claudiusmaxim
[Haskell-cafe] real-time audio processing [Was: can Haskell do everyting as we want?]
On Aug 3, 8:31 pm, Jeremy Shaw wrote: > The only area I have had any trouble with Haskell is doing realtime > music synthesis. And only because the garbage collector is not > realtime friendly. That is not unfixable though. However, I am > thinking that the best way to do realtime synthesis with Haskell is to > use it to create a DSL that uses LLVM to create code at runtime so > that the realtime code is outside the scope of the normal RTS and > garbage collector. I'm also very interested in this topic---how to apply a general- purpose functional language to real-time needs, even if it is in a domain-specific way. Indeed, it mostly comes down to memory management and the fact that functional concepts like closures and laziness require a lot of dynamic allocation and garbage collection. Certainly, one solution is to provide a real-time-friendly memory manager. However, it's interesting to notice that, as proven by FAUST [1], a huge amount of DSP algorithms can be expressed functionally in a real- time-compatible way by describing them as static diagrams of connected blocks. These can be efficiently compiled to imperative code with no dynamic memory allocation required. So yes, if such a language were available as an embedded DSL in Haskell (one effort can be found here [2]), it could be generated at run-time using LLVM and called out to. Alternatively, it would be very cool if it were possible to generate code statically at compile time, just like in FAUST. I can imagine this being very useful, especially if it could be generalized to operate on datatypes other than floating points, and had easy access to data structures provided by non-RT portions of the code. If there are mutability requirements, it could be made to run in the ST monad with a pre-allocated workspace. Of course _modifying_ such structures at run-time is always a dynamic thing by definition, although there is the possibility of dynamically generating a replacement block diagram while an one existing one runs, and using an atomic pointer swap to switch them without causing interruptions. In any case, as far as I know the only thing in the way is that it's impossible to tell GHC to compile a section of code in such as way as to guarantee avoidance of memory management. Compilers and runtime- systems always seem to be either RT- or non-RT-friendly, but never seem to support the idea of code *portions* that have differing requirements. My point is, RT code _can_ be expressed functionally, even if the RT-ness imposes certain expressivity restrictions. It would be very cool to be able to mark sections of code as following such a "sub-language" and be guaranteed that the compiler will generate GC-free code for a particular function, if possible, or otherwise fail. Even if such a sub-language were no more expressive than C, it would be nice to be able to write it in Haskell instead of dropping down to C, so that data can be easily shared with non-RT parts, and Haskell's type checker could be exploited. It seems strange to me that with technology like Haskell and GHC we still depend on using C to express these last remaining droplets of real-time determinism requirements--- strange, since I think of higher-level languages like Haskell to be supersets of the capabilities of C---and annoying, because it means having to deal with the complexities of language interoperability, just for a few low-level components of an application. I realize some of this has probably been discussed in conjunction with FRP. I'm aware of one paper on RT-FRP that talks about requiring an RT-friendly sub-language [3], but I don't pretend to follow it completely. I'm almost sure it also has something to do with arrows, but I have very little idea what they are, since I'm still just "getting" monads at this point in my personal Haskell understanding. I hope someone more knowledgeable about these things on this list might be able to comment on their relation to real-time determinism. [1] http://faust.grame.fr/ [2] http://claudiusmaximus.goto10.org/cm/2009-12-04_heist_dataflow_algebra.html [3] http://www.haskell.org/frp/rt-frp.pdf ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
