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