[LLVMdev] Evaluatin llvm for an application

[Maurizio De Cecco]

Le 26/01/2010 16:28, Tilmann Scheller wrote :
> Yeah, this is the right place, just ask :)

Thanks, here it goes ... :->

I am the current developer/maintainer of an application called jMax, 
that is part of a larger family of systems (Max, Puredata, etc) that
orinated in Ircam in the 80/90s.

The application is actually a visual progamming environment for sound
processing/synthesis applications.

You build an application by connecting small boxes, each of them
representing an operation of some kind. Operations can currently be
added in C, and they have very different level of granularity, from
integer addition to complex DSP operations.

The language support two model of computations, one that is event 
driven, and essentially is just a way to represent simple imperative
code with simple data types with a graph, and the other that is a data 
flow model used for DSP computation, where signal streams are 
implemented passing around vectors.

The language implementation is different with the two computational
model: the event/imperative part is interpreted; each box in the visual
language correspond to a kind of object, and the interaction between 
objects is implemented by message passing. The dataflow part is compiled
to a "virtual machine", actually a list of function calls that are 
performed one after the other following pointers to functions.

I am considering migrating the application to llvm, for both 
computational models, using runtime code generation.

This mail is to check that my understanding is correct expecially
regarding what i could gain; i'll details in the following.

1) Performance

When the granularity of the operations (both in the event model and in 
the data flow model) the execution time is dominated by the interpreted 
overhead, and not by the useful computation.

For the event based computation model, if each operation is coded in
LLVM (but it can be coded in C and compiled to LLVM to make life easier)
the execution overhead can essentially disappear, providing an 
improvement in performance of at least an order of magnitude; standard
LLVM optimisation should reduce operations to their assembler 
counterpart, without a lot of overhead instructions.

For the dataflow, the improvements may come esssentially from three 
factos: skipping the function calls thru pointers and inlining code,
using vector instructions for primitive operations, and possibly thru
vector code optimisation.

Currently, if the vector operations are simple, the system spend its 
time in looping and reading/writing data to the memory; optimisations 
like loop fusion can give a significant performance improvement. (can
LLVM do this kind of optimisation ?).I would expect an improvemnt of a
factor around 2, for small granularity operations, may be more.

2) Flexibility

The program work also as an integration environment, where wrapper 
operations allows to reuse existing plugins of various type within
the system. By generating and JITing the glue code at run time,
it would allows native level performance in using "foregneir plugin".
This would also allows the introduction of other ways of writing
operations (currently defined in a more or less weird Object Oriented
idiom built on top of C), like a real object oriented language like 
Objective-C or C++.

I understand that the above is quite too synthetic to understand the
details of the system and of what i would like to do, but it may rings
some bell. I would be glad to read any comments/suggestions and to 
answer questions on the details.

The last question: would the C API be enough for doing this kind
of work, or the C++ way would be mandatory ? Nothing against C++,
other than the fact i haven't touched it in the last 18 years :-< ..

Thanks for reading,

Maurizio De Cecco