Subject: [linux-audio-dev] large/finegrained plugins/opcodes issue ... optimizations
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Sun Mar 12 2000 - 09:59:32 EST
Hi,
I watched the large/finegrained discussion discussion:
Paul is saying he implemented some sort of compiler
which "compiles" opcodes into lists of function tables in
order to get more speed out of quasimodo.
But my idea is instead of using these tricks,
why not use the C compiler itself, at runtime:
assume we have a textual description of the opcode:
We use a preprocessor to convert it to a C source file,
we compile it as a .so file which can directly be used by
the plugin host.
If you modify the textual description of opcodes or add new opcodes,
then these modules automatically get recompiled to the .so files.
I think that assuming that a C compiler is available on a Linux box isn't a
big deal.
Plus consider the fact that such opcodes are pretty simple compared to
a complex app, therefore they get recompiled in a blink of an eye.
I think we would see a big performance boost using this approach.
For example tlooking at the modular synth Reaktor for Native Instruments (on
win and mac), I think that it probably uses a similar concept as Paul uses
in quasimodo.
But recompiling to native code (opcodes translated to C and then compiled
to an executable) would squeeze out the last % of performance out of the CPU
since it would save the function call overheads , lists etc.
It has to be determined yet how much we could gain in terms of performance,
but I think that in somecase of tricky opcodes, we may gain 50%-100% of
performance.
I discussed this idea with David Olofson, and we were both favorable about
using this approach in MuCos.
Any thoughts ?
Benno.
This archive was generated by hypermail 2b28 : Sun Mar 12 2000 - 18:28:07 EST