I have given a small amount of attention to OMP environment variables
controlling active (spinning) versus passive (sleeping) thread
barriers and controlling various scheduling policies. None seem to
make any significant difference.

The implication is that, in the head branch which now uses OpenMP, the
threading overhead is all down to thread activation/deactivation. This
will also have mostly to be true in the ParCS branch. This kind of
overhead appears to be irreducible.

The only path towards further improvement in multithreaded performance
seems to be optimizing the ParCS branch, and I do not expect much
improvement is possible there.But we will see!

The implication is that we can expect modest speedups from
multi-threading in Csound only at ksmps around 100 or more and only
with significant numbers of parallel instances of instruments.
Significant speedups come around ksmps 500 or more. Compute-intensive
instruments, of course, will benefit more. Note that at the current
studio standard of 96000 frames per second, 500 ksmps is 5.2
milliseconds, which is tolerable but not great control timing.

-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net