[LAD] Project proposition: llvm based dsp engine
letz at grame.fr
Thu Dec 9 13:24:58 UTC 2010
Le 9 déc. 2010 à 13:53, Maurizio De Cecco a écrit :
>> Le 8 déc. 2010 à 12:19, Maurizio De Cecco a écrit :
>>> On Tuesday12/7/10 2:58 PM, Stéphane Letz wrote:
>>>> I'm quite dubious of any real optimization you would achieve with this kind of approach, using LLVM.
>>>> AFAIKS LLVM link time optimization allows some kind of inter module inlining or possibly constant
>>> Well, optimizations can be added :->.
>>> Anyway, in my case (jMax, but it valid for other patch based langauges), things like inlining and loop fusion and software pipelining would help a lot for patches with simple objects like add and multiply.
>> Possibly, but this is somewhat limited to Max like languages...
> Probably, and to any applications that need to combine at run time a number of "relatively" simple
> signal operators.
>> I would suggest to first test the idea with LLVM: like writing simple modules in C, compile them with LLVM in bitcode, then use LLVM API to combine them using Link Time Optimization stuff.
>> Without any real benchmark of the approach it does not make real sense IMHO.
> I agree, the idea must be validated against some test case of some kind before
> investing time in coding.
> On the other side, LLVM is still moving quite fast, and it is a framework to
> write compilers (and tools and ...); any benchmark done today would just give
> you an indication of what it is possible today, with the existing optimisations,
> and not of the potentiality of the platforms.
> To get an idea of the potentiality of the platforms you would need some compiler
> expert of the LLVM project, not just the users.
>>>> Again staying in the imperative world makes things much more complicated... go functional!
>>> I was born as LISP programmer, so, nothing against, just tell me what to do with existing code bases :->
>> Rewrite them in Faust ((-:
>> You should come on Faust dev list...
> I have no doubt that Faust is a great system, and i am hoping to have time to write
> the needed code to generate jMax object from Faust.
> But i have a different problem, that is to maintain and evolve an existing code base,
> so the answer "there are better languages technologies", while true, it is not anyway
> the good answer.
>>> OK, may be it is just a dream, but LLVM seems to be an interesting framework to use for this purpose.
> [ ... ]
>> Not sure LLVM is the right basis for that.
> Well, it depends; it is a natural basis for a platform where LLVM is becoming the basic platform compilation
> technology, like Mac OS X. If we were discussing about Java programming, i would be discussion about
> JVM byte code generation ...
Sure LLVM is great by itself, I'm just saying that the LLVM Intermediate Representation is maybe not the best level to represent different DSP computation and hope sophisticated inter-object optimization will take place.
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.
More information about the Linux-audio-dev