Hi Istvan,

Although the complexity would be higher, I think it'd be worth it and
honestly don't think a solution where users explicitly set
dependencies would be something that would be any less easier.  If a
user has to determine all the pathways and dependencies and set it,
then it can really get in the way at composition time.  Also, I
realize now that instruments that exist in one orchestral context
could have dependencies listed but in another context where instrument
numbers are different, that information has to be redone.  I guess
that dependency information could be done outside of the context of
the instrument, maybe as far as to use another set of tags within the
the CSD (i.e. "<CsDependencies>").  On the other hand, I see it
possibly as a situation where figuring out dependency analysis can be
done once in the codebase or every time by users, and it's something I
think I'd prefer to do as a programmer rather than when I'm working on
music.

In terms of overhead, I didn't have an either-or implementation in
mind but rather a both-and.  I imagined something like this as a part
of the Csound run:

-initialize csound
-parse CSD
-if set to single processor, run current csound scheduler and render loop
-if set to multi processor (Csound could check if on multi-processor
machine), do analysis of instruments for dependencies and figure out
split of instruments and notes amongst processors, set up score queues
for each processor, then run alternate csound render loop
-if set to multi machine, account for heterogenous computer setup by
using information from a profiling session (would need a tool for this
and possibly factor out writing to disk overhead for render nodes that
may have slow hard drives but which won't be using them)

So the different schedulers and render loops would branch pretty high
up so would not incur any performance hit for the render loop for
single processor.

I think perhaps doing a mock implementation in python of just the
dependency analysis and scheduling across processors (wouldn't parse
csound CSD or anything like that, just very barebones objects like
"Instrument", "ReadGlobalVar", "WriteGlobalVar", etc. that labels the
different points of dependency) might be the way to start off.

Also, I'd like to note that a multi-processor, shared-memory
implementation of Csound has already been done in Extended Csound,
though I don't know any details beyond what has been publicly
available in papers online.  It does make me more hopeful though that
an implementation of such would be possible for Canonical Csound.

steven



On 4/13/06, Istvan Varga <istvan_v@fibermail.hu> wrote:
> On Thursday 13 April 2006 09:20, Steven Yi wrote:
>
> > 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.
>
> Well, not requiring the user to explicitly set up instruments for
> parallel operation would be nice, but then the complexity of
> implementation is much higher. Also, the overhead in the case of
> "normal" non-parallel operation would be increased, particularly
> with opcode level parallelism.
>
>
> -------------------------------------------------------
> 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