[LAD] Project proposition: llvm based dsp engine

Victor Lazzarini Victor.Lazzarini at nuim.ie
Fri Dec 10 22:01:50 UTC 2010


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 at lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20101210/32467c23/attachment.html>


More information about the Linux-audio-dev mailing list