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=lnk&kid0944&bid$1720&dat1642 _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net