Evaluatin llvm for an application

Hallo,

i am evaluating the possibility of using llvm for an application,
and i wondering if this is the right place where to pose questions.
I haven't found a llvm users mailing list ...

Maurizio De Cecco

Yeah, this is the right place, just ask :slight_smile:

hi,
LLVM does not have a specific user mailing list. Users are mostly ask their questions in this mailing list which actually use for the development of LLVM as well. Also you can try #llvm at irc.oftc.net.

Rajika

Le 26/01/2010 16:28, Tilmann Scheller wrote :

Yeah, this is the right place, just ask :slight_smile:

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