7 Dec
2010
7 Dec
'10
2:59 p.m.
Message: 3
Date: Mon, 06 Dec 2010 14:11:07 +0100
From: Maurizio De Cecco <jmax(a)dececco.name>
Subject: Re: [LAD] Project proposition: llvm based dsp engine
To: Paul Davis <paul(a)linuxaudiosystems.com>
Cc: The Linux Audio Developers' Mailing List
<linux-audio-dev(a)lists.linuxaudio.org>rg>, llvmdev(a)cs.uiuc.edu
Message-ID: <1291641067-065c11f3c738513db43420e758ad7e5d(a)dececco.name>
Content-Type: text/plain; charset="iso-8859-1"
Hi, and thanks for the feedback.
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 propagation (see
http://llvm.org/docs/LinkTimeOptimization.html) but I am not sure it would help a lot in
our domain.
Again staying in the imperative world makes things much more complicated... go
functional!
Stéphane
PS: BTW LLVM is a really nice tool and very interesting things can be done with it, like
using LLVM bitcode format as an interchange format for different architectures and using
the JIT for dynamic compilation. We can already do that with Faust LLVM backend where we
can generate a bitcode binary, then load it and JIT with a generic "LLVM faust
plug-in" loader. This would allow the same bitcode object to be produced by the Faust
online compiler for instance and be executed on any target machine.
My own gut feeling on this is that you'd be
better off figuring out
how to do this in the context of Faust, which already does a important
subset of what you are describing, though notably without (I think)
the LLVM part.
Surely a contribution to the discussion by the Faust people would
be welcome; and even more than to the discussion :->. By the way, they
do something with LLVM, but i do not know exactly what (Faust is included
in the list of projects using LLVM).
I think the interest, if any, would be in having a *low* level
library generic enough to be used by multiple applications, so
to factor the work. It may be that an existing project have internally
a large part of the needed code, though.
Note also that hosts which run plugins at the
level of LADSPA/LV2,
VST, AU, DSSI etc are unlikely to be easy candidates for any
cross-plugin optimization.
I was actually talking about two different context, reusing existing
binaries, and having cross plugin optimisations for native plugins.
But, if the plugins are compiled with a different compilation chain
(using the LLVM compiler producing LLVM byte code, so introducing a different
binary format for them), than cross plugin optimisation is possible also for
existing plugins like a LADSPA plugin.
Would that be worthwhile ? Difficult to know for sure, but it is an interesting
subject to explore.
Maurizio
7 Dec
7 Dec
3:25 p.m.
New subject: Project proposition: llvm based dsp engine
It's difficult to get rid of the C/C++ that has been burned into my
brain. But one day I'll get functional...
On 7 Dec 2010, at 13:58, Stéphane Letz wrote:
Again staying in the imperative world makes things
much more
complicated... go functional!
Stéphane
8 Dec
8 Dec
12:19 p.m.
New subject: Project proposition: llvm based dsp engine
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
propagation
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.
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 :->
PS: BTW LLVM is a really nice tool and very
interesting things can be done with it, like using LLVM bitcode format as an interchange
format for different architectures and using the JIT for dynamic compilation. We can
already do that with Faust LLVM backend where we can generate a bitcode binary, then load
it and JIT with a generic "LLVM faust plug-in" loader. This would allow the same
bitcode object to be produced by the Faust online compiler for instance and be executed on
any target machine.
Great: now image to use a common framework and standard to make Faust
generate bitcode interoperable with LLVM plugins generated with other
code, and to have an execution framework for these plugin that can be
shared between multiple applications.
That would solve quite a number of boring engineering problems, like
having wrapper for faust (for jMax, for Pd etc etc) objects for a dozen
or so of applications.
OK, may be it is just a dream, but LLVM seems to be an interesting
framework to use for this purpose.
Maurizio
1:42 p.m.
New subject: Project proposition: llvm based dsp engine
Le 8 déc. 2010 à 12:19, Maurizio De Cecco a écrit :
Rewrite them in Faust ((-:
You should come on Faust dev list... You would see how Julius Smith is writing some quite
interesting DSP code, by designing basic blocks and libraries, then uses them in very
impressive examples.
Even if Faust is still limited (even if we are hard working on the multi-rate Faust 2
version...), we still think the " write functional DSP code" then use a
"semantic based compiler and optimizer" approach to be the most promising in the
long term.
Not sure LLVM is the right basis for that.
Stéphane
On Tuesday12/7/10 2:58 PM, Stéphane Letz wrote:
Possibly, but this is somewhat limited to Max like languages...
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'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
propagation
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. 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 :-> PS: BTW LLVM is a really nice tool and very
interesting things can be done with it, like using LLVM bitcode format as an interchange
format for different architectures and using the JIT for dynamic compilation. We can
already do that with Faust LLVM backend where we can generate a bitcode binary, then load
it and JIT with a generic "LLVM faust plug-in" loader. This would allow the same
bitcode object to be produced by the Faust online compiler for instance and be executed on
any target machine.
Great: now image to use a common framework and standard to make Faust generate bitcode
interoperable with LLVM plugins generated with other code, and to have an execution
framework for these plugin that can be shared between multiple applications.
That would solve quite a number of boring engineering problems, like having wrapper for
faust (for jMax, for Pd etc etc) objects for a dozen or so of applications.
OK, may be it is just a dream, but LLVM seems to be an interesting framework to use for
this purpose.
Maurizio
9 Dec
9 Dec
1:53 p.m.
New subject: Project proposition: llvm based dsp engine
Le 8 déc. 2010 à 12:19, Maurizio De Cecco a écrit :
Probably, and to any applications that need to combine at run time a number of
"relatively" simple
signal operators.
On Tuesday12/7/10 2:58 PM, Stéphane Letz wrote:
Possibly, but this is somewhat limited to Max like languages... 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
propagation
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. 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 :-> > 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 ...
Maurizio
2:25 p.m.
New subject: Project proposition: llvm based dsp engine
Le 9 déc. 2010 à 13:53, Maurizio De Cecco a écrit :
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.
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.
Stéphane
Le 8 déc. 2010 à 12:19, Maurizio De Cecco a écrit
:
Probably, and to any applications that need to combine at run time a number of
"relatively" simple
signal operators.
On Tuesday12/7/10 2:58 PM, Stéphane Letz wrote:
Possibly, but this is somewhat limited to Max like languages... 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
propagation
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. 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 :-> > 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 ...
5158
days inactive
5160
days old
linux-audio-dev@lists.linuxaudio.org
5 comments
3 participants
participants (3)
-
Maurizio De Cecco -
Stéphane Letz -
Victor Lazzarini