On Mon, 27 Sep 2010, Ludwig Maes wrote:
I think that if we could write a Pd => GIMPLE converter (hence a Pd
frontend) for gcc, that gcc could do quite a lot of optimization for us.
What's the advantage over simply producing a large lump of C code ?
Because, learning GIMPLE takes time, whereas learning C... everyone
willing to take on that task already knows all of C.
I could be wrong but I have the impression that every message between Pd
objects is sent as an abstracted structure and not optimized for
architecture to the extent compilers do (could be wrong, but would be
positively amazed if I am).
Pd is often hard to categorise, but I'd call its message-system an « AST
intepreter », even though the «T» is supposed to stand for Tree, and it's
not a Tree in the context of Pd. An AST interpreter is faster than one
which constantly reparses, but is usually at least a bit slower than
bytecode, which is much slower than a conversion to C compiled with -O0.
This ability would further not only the goals of optimization freaks but
also those of dataflow programming in general (stepping into C or other
is like admitting -whether correct or not- dataflow is insufficient, at
least in practice as long as we cant compile...) Also people would be
able to write general software in dataflow languages. Whether it be
drivers, pd-developer code, ...
Dataflow programming as a whole is not a programming paradigm, it's a
collection of them. The Pd/Max paradigm could be called « imperative
dataflow » (in the case of the message-system). Before I came, the
totality of programming languages called dataflow had very little to do
with Pd/MAX, while Pd/MAX weren't called dataflow ; and those that were
called dataflow didn't always have so much to do with each other. There
are still lots of researchers who use the phrase « dataflow programming »
in a specific manner that excludes Pd/MAX. Anyway, what I want to say is
that there is not much that you can do that can apply to the whole of what
is called dataflow.
We could bootstrap Pd for example, so that users who at first use Pd
for audio, then start to code in GEM later could also start to adapt
their interface or fix inner workings of Pd
I don't understand what you mean.
_______________________________________________________________________
| Mathieu Bouchard ------------------------------ Villeray, Montréal, QC
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
