Re: [PD] PureData to C/C++ language
On Tue, 28 Sep 2010, Ludwig Maes wrote: I would think that having an extra intermedia language would hide information from the middle end, I trust that the gcc developers know what they do, otherwise by the same argument it would be much easier for the other GCC front ends to compile to C and hand that over to the C compiler and thus indirectly to the middle end. It's easier to compile C++ to C, but typically, compiler writers would consider it cleaner to have a direct compilation to asm. But then, I recall that on MSDOS, the norm was instead to compile straight to machine code. Much of the reason was to skip encoding/decoding steps. You may trust the gcc developers but we're not the gcc developers, and they're not the ones likely to write you a pd frontend. Since all the supplied front ends emit gimple I think there are good reasons for this. That's because the other compilers that emit C or close derivatives of C are produced by other people than the GCC team, and they are compilers that don't benefit from nearly as much visibility as the GCC team. One example of why I think taking the detour (in code transformations, but possibly shortcut in ease of programming) along C would be organizing code into threads, since C/C++ were originally not develloped for multithreading but assumed a rather pure Von Neumann architecture. Excuse me, I don't understand this sentence. (I think it's missing some words near the beginning.) BTW, Pd isn't any more threadable than C. Pd isn't part of the same family of dataflow languages as most other dataflow languages (one family of which is designed to be threadable). I don't know where you want to go with that topic though. As I said I dont really know the message system, I just notice my system monitors network histogram (on ubuntu) soar as I use Pd. Surely passing information through registers when possible would be faster, or are processor caches even aware of Pd messaging system? Use of registers has been done automatically by GCC since the last 15 years or more. Because of this, I don't even hear about registers anymore... almost. Use of L1, L2 and L3 caches is also completely automated by default for all apps, but that's a motherboard thing. However, much of Pd is interpreted, and that usually involves processing a much larger amount of conditionals, switches and function pointers than what usually happens in compiled code. But are you sure you are talking about the message system only, and not about dsp ? do you use specific collections of externals such as gem,pdp,gridflow,vasp,iemmatrix,pmpd, that may operate on large collections of data while using very little of the interpreter...? it may make the interpreter irrelevant. I know that since at least the sixties there was 'dataflow' (I got interested in dataflow because I stumbled on old MIT papers about them, back when they tried to make 'dataflow' hardware before it appeared to be inefficient for multiple reasons...). do you mean this ? - http://en.wikipedia.org/wiki/Connection_Machine but that was in the eighties. I know dataflow means a lot of different things. This is not mathematics. Mathmatics is more standardised than computer science, but mathematicians of the world are still divided in two, according to whether natural numbers include zero or not, and whether zero is called a 'positive' number or not. I realise that even if people were willing to create such a system, that there would be multiple possible graphlike languages, each with their pros and cons. What is more important to me is that one would be made, so that people who stand for different forms of dataflow programming would adapt it to their needs or respond to a higher bar by making their dataflow language compilable through existing compiler middle ends. Show me people who want to collaborate on a thing like this that would include Pd... because I don't believe you can get such a team together. The dataflow families don't have so much in common. Suppose Pd (or other dataflow language) were rewritten in the dataflow language, so that Pd almost becomes a sub operating system, to run a mixture of uncompiled and compiled code (for example in theory if the sources of running code (including Pd) were provided in the dataflow format, then during normal usage, a user could freeze the program, change and recompile part of the graph and continue the program...) You don't need to bootstrap Pd to recompile any part of a graph. Specifically, you need a graph compiler than can work on any part of a graph. Bootstrapping is a cool concept, but its advantages are harder to find. Another example: a user want bezier curves to connect the boxes, or color code hot inlets, or ..., then he could adapt Pd gui to do so without having to know C (like a lot of the now supposedly 'only artistic' user base, which in my view are programmers, but just program Pd instead of C).
Re: [PD] PureData to C/C++ language
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___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PureData to C/C++ language
As I said, I am no expert at all in this, but I can explain what motivated me to make these specific remarks, and express my beliefs or doubts: On 28 September 2010 19:35, Mathieu Bouchard ma...@artengine.ca wrote: 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 would think that having an extra intermedia language would hide information from the middle end, I trust that the gcc developers know what they do, otherwise by the same argument it would be much easier for the other GCC front ends to compile to C and hand that over to the C compiler and thus indirectly to the middle end. Since all the supplied front ends emit gimple I think there are good reasons for this. One example of why I think taking the detour (in code transformations, but possibly shortcut in ease of programming) along C would be organizing code into threads, since C/C++ were originally not develloped for multithreading but assumed a rather pure Von Neumann architecture. 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. As I said I dont really know the message system, I just notice my system monitors network histogram (on ubuntu) soar as I use Pd. Surely passing information through registers when possible would be faster, or are processor caches even aware of Pd messaging system? 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. Here I must say that I hesitated a lot and didnt know how to phrase it. I know that since at least the sixties there was 'dataflow' (I got interested in dataflow because I stumbled on old MIT papers about them, back when they tried to make 'dataflow' hardware before it appeared to be inefficient for multiple reasons...). I know dataflow means a lot of different things. This is not mathematics. I realise that even if people were willing to create such a system, that there would be multiple possible graphlike languages, each with their pros and cons. What is more important to me is that one would be made, so that people who stand for different forms of dataflow programming would adapt it to their needs or respond to a higher bar by making their dataflow language compilable through existing compiler middle ends. These wouldnt directly apply to the whole of dataflow, but at least it could create courage to the whole to apply compilability to their specific view of 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. Suppose Pd (or other dataflow language) were rewritten in the dataflow language, so that Pd almost becomes a sub operating system, to run a mixture of uncompiled and compiled code (for example in theory if the sources of running code (including Pd) were provided in the dataflow format, then during normal usage, a user could freeze the program, change and recompile part of the graph and continue the program...) Another example: a user want bezier curves to connect the boxes, or color code hot inlets, or ..., then he could adapt Pd gui to do so without
Re: [PD] PureData to C/C++ language
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. 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). 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, ... 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, in my view the original poster is a vote towards this end. The opensource fanatics fear could be that software written in Pd, could be shared in a non-opensource way. I have the impression this is the reason none of the devellopers work on this: http://puredata.info/docs/faq/standalone states: This is currently not possible to compile a patch into a binary program. Pd patch files are always plain text and need the Pd program to run. However, the main reason why Max/MSP and similar allow you to create a standalone application is to distribute a patch without having to pay license fees to the distributor. Since Pure Data is Free Software, you can just distribute your patch along with the needed Pd binary. On Mac OS X, Pd-extended 0.41.4 makes it easy to make such a distribution. You can make a standalone .app using the Make app from menu options in the File menu. First it is mentioned that it is currently not possible (without any concrete reference to existant intention or not) Then it inverts the reason why Pd does or does not have this to the reason why Max/MSP have mechanisms to distribute without having to pay the distributor (being Max/MSP?) as opposed to the patch creator? Without speaking for the original poster, I view his question as a desire for compiling dataflow (in his example Pd). He clearly states he searches for a way to do this without having to recode the entire patch (devaluating his original work in Pd itself). That a similar question resides in Frequently (!) Asked Questions confirms my suspicion that there is a user base which would benefit from such possibility. I think as soon as the GIMPLE Front End has materialized enough (currently a Google Summer of Code project) would be a very good time to design a Pd = Gimple converter (Front End). (GIMPLE is the intermediate language AST GCC uses, C++ and other Front Ends convert to GIMPLE so that language independent optimization can take place). I am searching for people who would be interested in helping this make happen, having a list of emails of interested people could be a good start. Every year computer science students around the world have to design a simple compiler in their education programme. Chances are a few of them are interested in Pd already. Some might be allowed to write a Pd front end by their teachers. We Pd users are also not incapable to do this. Lets get together and make this happen! Greetings! On 25 September 2010 20:45, ankur gandhe ankoo...@gmail.com wrote: I was working on a Sound renderer project made in PD and to reduce the latency, we wanted to write the module in C, implementing all the features. Is their a simple way of doing so? If so, please do help Ankur ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PureData to C/C++ language
On 2010-09-27 10:38, 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. you might be interested in the Pd compiler presented at nime08: http://nime2008.casapaganini.org/documents/Proceedings/Posters/238.pdf fgmasdr IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PureData to C/C++ language
On Mon, 27 Sep 2010, IOhannes m zmoelnig wrote: On 2010-09-27 10:38, 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. you might be interested in the Pd compiler presented at nime08: http://nime2008.casapaganini.org/documents/Proceedings/Posters/238.pdf But where does one download that software ? ___ | Mathieu Bouchard -- Villeray, Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PureData to C/C++ language
http://www.media.mit.edu/resenv/PuDAC/sw.html Bottom of the page. On 09/27/2010 10:48 PM, Mathieu Bouchard wrote: On Mon, 27 Sep 2010, IOhannes m zmoelnig wrote: On 2010-09-27 10:38, 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. you might be interested in the Pd compiler presented at nime08: http://nime2008.casapaganini.org/documents/Proceedings/Posters/238.pdf But where does one download that software ? ___ | Mathieu Bouchard -- Villeray, Montréal, QC ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- // ailo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] PureData to C/C++ language
I was working on a Sound renderer project made in PD and to reduce the latency, we wanted to write the module in C, implementing all the features. Is their a simple way of doing so? If so, please do help Ankur ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PureData to C/C++ language
I didn't understand your problem, but if you are looking for a simpler way to write c++ dsp code you can try Faust. Then you can have a pd object-box, a supercollider ugen or a ladspa plugin with the same code. For the latency problem try to optimize your operating system for audio work, maybe try a real-time kernel. (sorry if this is obvious, but you didn't give any details...) 2010/9/25 ankur gandhe ankoo...@gmail.com: I was working on a Sound renderer project made in PD and to reduce the latency, we wanted to write the module in C, implementing all the features. Is their a simple way of doing so? If so, please do help Ankur ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PureData to C/C++ language
On Sat, 25 Sep 2010, Bernardo Barros wrote: I didn't understand your problem, but if you are looking for a simpler way to write c++ dsp code I think that he wants to write an external in C, that's all. Ankur, you could try reading http://pdstatic.iem.at/externals-HOWTO/node6.html ___ | Mathieu Bouchard -- Villeray, Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PureData to C/C++ language
Well, actually I think I dint word my query properly. I already have a module made in PD. All I want to do this RE_WRITE this same module in C. I wanted to know if there is an easy way of doing it, or will I just have to write it again. I mean, is there a tool that directly converts the PD into C or something? Ankur On Sun, Sep 26, 2010 at 6:17 AM, Mathieu Bouchard ma...@artengine.cawrote: On Sat, 25 Sep 2010, Bernardo Barros wrote: I didn't understand your problem, but if you are looking for a simpler way to write c++ dsp code I think that he wants to write an external in C, that's all. Ankur, you could try reading http://pdstatic.iem.at/externals-HOWTO/node6.html ___ | Mathieu Bouchard -- Villeray, Montréal, QC ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PureData to C/C++ language
It's also worth mentioning that rewriting a patch as an external in C won't necessarily decrease latency or improve CPU efficiency. On Sat, Sep 25, 2010 at 8:47 PM, Mathieu Bouchard ma...@artengine.ca wrote: On Sat, 25 Sep 2010, Bernardo Barros wrote: I didn't understand your problem, but if you are looking for a simpler way to write c++ dsp code I think that he wants to write an external in C, that's all. Ankur, you could try reading http://pdstatic.iem.at/externals-HOWTO/node6.html ___ | Mathieu Bouchard -- Villeray, Montréal, QC ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- William Brent www.williambrent.com “Great minds flock together” Conflations: conversational idiom for the 21st century www.conflations.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PureData to C/C++ language
On Sun, 26 Sep 2010, ankur gandhe wrote: Well, actually I think I dint word my query properly. I already have a module made in PD. All I want to do this RE_WRITE this same module in C. Yeah, but is it going to be a C module for Pd, or a C module for some other framework ? (or for no framework at all) ___ | Mathieu Bouchard -- Villeray, Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
