Hi Michael, I don't think it's necessary for instruments that send signals one way to require them be in the same address space; if the first instrument is acting only as source to the next instrument, then the first instrument can render ahead of time all samples and send to the next instrument as necessary in buffered blocks. Anyways, even though much more complicated, I would prefer a solution where one does not have to explicitly design--as a user--their orchestra to perform in a parallel situation, and that that work is automatically done by Csound. On a side note, I just upgraded to Fedora Core 5 last night and today I recompiled Csound5 with gcc 4.1. I had read that in 4.1 that gcc is now starting to take advantage of the tree-ssa stuff they did for 4.0 to do some code optimization when compiling. I did a render of one of the parts from my Etude and it *seemed* to have rendered more quickly. i didn't take a metric though so can't say for sure if that is the case. Has anyone done some testing with Csound compiled with 3.x, 4.0, and 4.1 and have some metrics on performance? (Just curious to know if I'm imagining things or not =) ). steven On 4/9/06, Michael Gogins wrote: > I think a simpler design would suffice. > > Instruments that send signals to each other would of course have to be in > the same address space. But I think for now, it would be enough to manually > assign them to groups with a new opcode: > > igroup depends myinsno, otherinso1, otherinso2,...,otherinson > > Global signals could be handled with something like OSC. > > Other than that, all that's necessary is for each group to skip all "i" > statements except those assigned to it, and to collect audio into a common > output (again, with a new opcode): > > netout igroup, achn1, achn2,...achnn > > This opcode would need a semaphore so that each process would wait after > output until all processes have output and the current ksmps or buffer has > been written to the master output. But this would be pretty easy to do. > > Duplicating ftables, orchestras, and so on is no big deal on current > machines. Address space, disk space, and network speed are negligible in > comparison with sheer processor overhead and cache hits. > > I don't think parallelizing at the opcode level is a good idea unless the > transfer of a-rate variables across address space boundaries is much more > efficient than it is likely to be -- there are dozens or hundreds of these > transfars for each input or output transfer. > > I'm wondering if this would be very usable in live performance compared to > just having a fast processor and a lot of memory, but I am quite confident > it would extremely helpful in rendering off-line -- it would enable the > limit of what is practical with Csound to jump an order of magnitude, > probably. > > Regards, > Mike > > ----- Original Message ----- > From: "Steven Yi" > To: > Sent: Sunday, April 09, 2006 11:48 PM > Subject: Re: [Cs-dev] Object design question for API use > > > Hi All, > > Sorry for taking a while to chime in, but I thought I'd mention I've > been very interested in a csound that could scale both across > processors for multi-core chips and also scale across a heteregenous > network of machines. The interest though has not been for > collaborative playing though the ideas for the design of a parallel > csound should be able to work with some careful handling of the input > data from performers. > > Some things that's been on my mind regarding this: > > -there would have to be an analysis phase to determine dependencies > after compilation but before rendering > > -a dependency graph could be generated from comparing opcodes against > a database of known dependency features so that the dependency info > could be developed from the data structures currently in place; this > would require work to keep the known information in sync, but it would > then not affect memory requirements by adding more information to the > data structure, and also would have the advantage of being developed > separately. May be easier to work with then for the case of opcode > plugins so that no discovery mechanism would have to be implemented to > identify the dependencies. > > -there's a lot of issues involved with analyzing dependencies between > instruments (communication via global variables, zak, software bus, > ftable, etc.) and on other things like ftables and external files(i.e. > audio files, text files used for ftables, etc.). Some of these are > easier when there is a shared-memory situation (multi-core processor) > but are trickier in a distributed situation. Ftables seem particularly > troublesome to analyze the graph of dependencies especially if the > ftable number is coming in via a pfield in an i-statement. > > -partitioning work between processors or between computers could have > different strategies depending on realtime or disk render > > -Endianess would be a factor for communication > > -curious about strategies where other processors could render their > load ahead of time while the main host processor would grab as > possible to max out the processing > > It seems that the best chance of getting noticable performance > increase would be from a shared-memory system versus a distributed > system, which may be a good way to go as it seems Intel Core Duo > processors are becoming the standard for the current round of laptops, > and multicore chips seem to be on the horizon all around. > > Most of the ideas I've had so far mainly revolve around partitioning > the problems and scheduling at instrument/note level, but there could > also be some significant gains from parallelizing at the opcode level, > or by an opcode-by-opcode basis. I'm not sure if doing it at that > granular a level and to also do it at a higher level would take away > from each other though if they compete without knowing about each > others demands on the CPU. > > Just some of what's going on in my mind lately; I'm still just getting > into researching into parallel computing in earnest and am very > interested to see something like this possible with Canonical Csound. > > steven > > > On 4/8/06, Michael Gogins wrote: > > Sure, I'd like to see your code. BTW, I doubt string processing is going > > to > > add any significant overhead either. When it comes to overhead, think > > about > > functions to call, bytes to move or access, and multiplications to do. > > Obviously in an audio synthesizer the audio processor overhead will > > usually > > far outstrip anything else. Doing 100 string transfers x 64 characters a > > second (or even 1000) will be small compared to doing 44,100 x 2 channels > > x > > 8 bytes a channel transfers a second, and of course the audio > > multiplications are far beyond any string processing or GUI event > > processing > > (any stuff the GUI does to move pixels around is now on a separate card > > with > > its own memory and processor, so forget that). > > > > Regards, > > Mike > > > > ----- Original Message ----- > > From: "Iain Duncan" > > To: ; "Michael Gogins" > > > > Sent: Saturday, April 08, 2006 11:20 PM > > Subject: Re: [Cs-dev] Object design question for API use > > > > > > >> It's in line with my own experience that synchronization overhead is > > >> quite low. > > > > > > Yeah, I just checked again, and if the display is not updating 128 > > > knobs, the cpu diff is about 2% for me. So well worth it! > > > > > >> What I suggest is that you go ahead and do the multi-Csound, > > >> audio-mixing part now and get it out there. A lot of people would be > > >> interested in using this, especially for rendering big complex pieces > > >> off-line. > > >> > > >> If and when you do this, be SURE to make the connections/queues between > > >> different instances of Csound and the mixer that blends them ABSTRACT > > >> so > > >> that they can be network connections. Then Csound would be clusterable. > > >> Then the instrument definitions could basically be as elaborate as one > > >> would like. > > > > > > The multi-csound part is less of a pressing concern for me than certain > > > other components, *but* I very much want to get the base right to enable > > > that. If that is something you are interested in and able to help with, > > > I will make the multi-csound part a higher priority. A multi-user setup > > > with clustering csound on multi-cpus would rock for live improvised > > > computer music! > > > > > > May I send you my base module code for comment/criticism? As is, it is > > > working, but I think it would be good to add the ability to put an > > > arbitrary string into the message. However, I don't want to unecessarily > > > slow down message transfer. Perhaps the message structure should depend > > > on the message type? Ideally, the message structure should be flexible > > > enough that ALL communication between ALL modules happens as messages > > > send from modules to the controller and vice versa. I forsee needing a > > > string in there to send error messages to guis, allow sending of csd > > > filenamens, and use for OSC messages if necessary. At the same time, > > > this message will also be used to write a single audio sample in to > > > csound in the case of loading audio files remotely, so we want to keep > > > that as quick as possible. > > > > > > Thanks > > > Iain > > > > > > > > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by xPML, a groundbreaking scripting > > language > > that extends applications into web and mobile media. Attend the live > > webcast > > and join the prime developer group breaking into this new coding > > territory! > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > > _______________________________________________ > > Csound-devel mailing list > > Csound-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/csound-devel > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=k&kid0944&bid$1720&dat1642 > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel > ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net