Le 9 déc. 2010 à 22:17, Maurizio De Cecco a écrit : > On Thursday12/9/10 2:24 PM, Stéphane Letz wrote: > >> By since you have a lot of jMax object coded in C, I guess testing the idea >> with the current jMax environment should be easy: just compile your jMax >> objects in LLVM bitcode ad try to "combine" (Link Time Optimization) them >> with LLVM API. > > > Exactly (well, more or less). > One interesting point is the control part; it is theoretically possible to > get a control patch made of simple objects (things like ints, operators, > trigger, if) up to native C speed. > > This would require writing objects in a slightly different way. > > Anyway, for the moment all this is out of reach, not enough time. > But you never know :-> > > Maurizio
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 [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
