Le 2011-11-24 à 10:04:00, Jonathan Wilkes a écrit :
Is there a way to take a pd patch and compile it to c or c++ or something?
There are ways to do various kinds of compilations of pd patches, and at least one has been tried, but the source of C-based classes is not designed to be inlined into a compilation output, therefore much work has to be redone by a compiler if you want to make more optimisation. (It's not like I really have a solution in the back of my head for this.)
Pd's DSP is faster. It involves processing data in larger chunks of 64 floats by default (see above about too many tiny pieces) and it compiles patches as «wordcode»,
What is wordcode? Is that what's happening in d_ugen.c?
The term «wordcode» isn't nearly as widespread as the word «bytecode» is, and essentially, they're much of the same strategy, but the stereotype for bytecode is that the code is run by looping through a char[], whereas for wordcode, you're looping through a void*[] or something like that. In pd, t_word is a type which has the same size as a C pointer.
d_ugen.c is building sequences of pointer-sized variables. Each instruction is one function pointer followed by any number of items. Each instruction is provided by a dsp_add call made in each dsp-function of each tilde-external. The function pointer points to what is called a perform-function. Each perform-function is supposed to know how long the instruction is because it has to return the pointer to the next instruction (return w+5; and such).
[#expr] also uses some kind of word code. Each instruction is a t_atom, which is a pair of pointer-sized variables (with a lot of slack in them). [#expr] 9.12 defines several custom atom-types and [#expr] 9.14 defines two or three more for optimisation. I expect that a later version might scrap this and switch to some other similar scheme using t_word or void* instead of t_atom... if it is to become faster than [expr].
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC