Re: [LAD] Project proposition: llvm based dsp engine

From: Victor Lazzarini <Victor.Lazzarini@email-addr-hidden>
Date: Sat Dec 11 2010 - 00:01:50 EET

This is all very interesting. One question I had regarding the future
development of FAUST is whether it will include some sort of scheduler
so that various faust-coded objects can be instantiated at different
times, connected together in series, etc.. Then an interpreter could
be developed with JIT compilation etc.

Or is this more like the idea of combining FAUST with another language
like pure?

Victor
On 10 Dec 2010, at 12:28, Stéphane Letz wrote:
>>
>
> Well what could be interesting to share would be something similar
> to the "FIR" (Faust Intermediate Language) that we are currently
> designing and implementing.
>
> Basically Faust currently does :
>
> Faust dsp program ==> [BDA (Block Diagram Algebra) evaluation ] ==>
> Signals ==> FIR loops DAG (Direct Acyclic Graph) ==> C/C++, JAVA,
> LLVM, (possibly CUDA, OpenCL at some point) backends.
>
> FIR is a imperative like language where a Faust program is
> represented as a data structure + list of functions (init,
> buildInterface, compute...). The "compute" function does the actual
> DSP computation and is currently executing the DSP loops DAG in
> different modes:
>
> 1) vector mode : the loops DAG is simply topologically sorted and
> compiled in the target language (C/C++, LLVM...). The we hope GCC or
> ICC auto-vectorization features can do the job to produce SIMD code.
>
> 2) OpenMP mode: OpenMP pragmas are inserted at the right place in
> the DAG to express parallelism (and each loop can possibly be auto-
> vectorized).
>
> 3) Work Stealing Scheduler : the loops DAG is compiled with an
> "embedded" WSS algorithm (and each loop can possibly be auto-
> vectorized).
>
> 2) and 3) steps are typically expressed as "FIR to FIR"
> transformations.
>
> It could be possible to let other tools enter the chain before the
> "FIR loops DAG" step so that to take benefit of all the later
> steps : FIR to FIR parallelisation, and all available backends. We
> can even imagine to implement some kind of "inter plug-in"
> optimizations at the FIR level.
>
> But of course the simplest way to produce this "FIR loops DAG" is...
> using Faust itself, and "inter plug-in" optimizations are way
> simpler to handle at the Faust level (basically at the "signal
> step") . So I don't know if the idea makes sense, but you never
> know :->
>
> Stéphane
>
>
>
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev@email-addr-hidden
> http://lists.linuxaudio.org/listinfo/linux-audio-dev

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Sat Dec 11 00:15:03 2010

This archive was generated by hypermail 2.1.8 : Sat Dec 11 2010 - 00:15:03 EET