On Mon, 17 Dec 2007, IOhannes m zmoelnig wrote:
so all in all, messages are way more powerful than signals.
Especially as one could "reimplement" signals using messages as their
base. Oops, this is already how signals are implemented! They have this
method for the "dsp" selector. Granted that calling this method does not
process the data, it merely sets up a stream through which the data is
sent, but then, so is the "grid" selector in some other software.
unfortunately, CPU is not. that is one reason, why the oh-so-powerful
messages are not used for signal processing.
It's quite doable to use messages for DSP and have it run fairly fast, if
you use the same "fake pointers" as GEM/PDP/etc do, to point to a 64-float
array. It could even just use lists of 64 floats and it wouldn't be that
much slower. The only major thing you really lose is automatic fan-in,
unless special additional tricks are used. Actually, Christian Klippel's
Karma does DSP like that. The DSP compiler simply takes advantage of the
exactly-one-block-per-tick characteristic of the signals, to save some %
of the cpu and of the cache ram. This is one optimisation that can't be
done on the message side, but there are many more optimisations that could
be explored, on both sides separately and on both sides together.
_ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
_______________________________________________
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
