I attach a revised and, I think, much improved version of my paper on
different versions of concurrent rendering in Csound.

In particular, I have debugged the PARCS configuration and reviewed
Wilson's thesis describing its design, so I think I have a much
improved understanding of the PARCS design.

I also was able to get the spinlocks version of the OpenMP design
working and tested. Unfortunately, they didn't seem to help much.

Please let me know your thoughts.

Regards,
Mike

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

Thanks Michael,
The document is of great help when trying to understand the issues and
methods of concurrency,
and it is very valuable to have the different techniques described and
examined in one single document.
Thanks a lot.
Oeyvind

2012/10/1 Michael Gogins :
> I attach a revised and, I think, much improved version of my paper on
> different versions of concurrent rendering in Csound.
>
> In particular, I have debugged the PARCS configuration and reviewed
> Wilson's thesis describing its design, so I think I have a much
> improved understanding of the PARCS design.
>
> I also was able to get the spinlocks version of the OpenMP design
> working and tested. Unfortunately, they didn't seem to help much.
>
> Please let me know your thoughts.
>
> Regards,
> Mike
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
> ------------------------------------------------------------------------------
> Got visibility?
> Most devs has no idea what their production app looks like.
> Find out how fast your code is with AppDynamics Lite.
> http://ad.doubleclick.net/clk;262219671;13503038;y?
> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



-- 

Oeyvind Brandtsegg
Professor of Music Technology
NTNU
7491 Trondheim
Norway
Cell: +47 92 203 205

http://flyndresang.no/
http://www.partikkelaudio.com/
http://soundcloud.com/brandtsegg
http://soundcloud.com/t-emp

------------------------------------------------------------------------------
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi Michael,

Thanks for the updated document and thoughts within it.  It seems we
still have a lot to experiment with, particularly work partitioning
strategies, and parallellism in series.  I imagine if we move direct
mixing to SPOUT out of the out opcodes, and modify to write to a local
spout and mix, we could do some interesting improvements (well, this
might go for all resources, to do delayed writing/mixing when
possible).

Perhaps we should come up with a test suite of CSD's that illustrate
different scenarios?  Might be good to have some specific tests in
addition to the full-piece tests.

Thanks!
steven

On Mon, Oct 1, 2012 at 4:41 AM, Michael Gogins  wrote:
> I attach a revised and, I think, much improved version of my paper on
> different versions of concurrent rendering in Csound.
>
> In particular, I have debugged the PARCS configuration and reviewed
> Wilson's thesis describing its design, so I think I have a much
> improved understanding of the PARCS design.
>
> I also was able to get the spinlocks version of the OpenMP design
> working and tested. Unfortunately, they didn't seem to help much.
>
> Please let me know your thoughts.
>
> Regards,
> Mike
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
> ------------------------------------------------------------------------------
> Got visibility?
> Most devs has no idea what their production app looks like.
> Find out how fast your code is with AppDynamics Lite.
> http://ad.doubleclick.net/clk;262219671;13503038;y?
> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I think a test suite is a good idea. I would prefer it if there was a
Python test script that would use the subprocess module to run the
tests and scape stdout to determine results, with a config file to
select tests; results would then be written to a table in a text file
that could be opened as a spreadsheet. That said, this is a big piece
of work and I'm not eager to take it on... perhaps we could start with
just multithreading and move other tests in as they become important.

I don't understand why you think moving away from direct mixing is
good, the locking contention in all the concurrent designs seems a
very small part of the total threading overhead, it mostly seems to
come from having too many idling worker threads. But I could be wrong.
We may need to re-do the profiling with debug versions of the pthreads
and gomp libraries.

Best,
Mike


On Mon, Oct 1, 2012 at 11:12 AM, Steven Yi  wrote:
> Hi Michael,
>
> Thanks for the updated document and thoughts within it.  It seems we
> still have a lot to experiment with, particularly work partitioning
> strategies, and parallellism in series.  I imagine if we move direct
> mixing to SPOUT out of the out opcodes, and modify to write to a local
> spout and mix, we could do some interesting improvements (well, this
> might go for all resources, to do delayed writing/mixing when
> possible).
>
> Perhaps we should come up with a test suite of CSD's that illustrate
> different scenarios?  Might be good to have some specific tests in
> addition to the full-piece tests.
>
> Thanks!
> steven
>
> On Mon, Oct 1, 2012 at 4:41 AM, Michael Gogins  wrote:
>> I attach a revised and, I think, much improved version of my paper on
>> different versions of concurrent rendering in Csound.
>>
>> In particular, I have debugged the PARCS configuration and reviewed
>> Wilson's thesis describing its design, so I think I have a much
>> improved understanding of the PARCS design.
>>
>> I also was able to get the spinlocks version of the OpenMP design
>> working and tested. Unfortunately, they didn't seem to help much.
>>
>> Please let me know your thoughts.
>>
>> Regards,
>> Mike
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>> ------------------------------------------------------------------------------
>> Got visibility?
>> Most devs has no idea what their production app looks like.
>> Find out how fast your code is with AppDynamics Lite.
>> http://ad.doubleclick.net/clk;262219671;13503038;y?
>> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
> ------------------------------------------------------------------------------
> Got visibility?
> Most devs has no idea what their production app looks like.
> Find out how fast your code is with AppDynamics Lite.
> http://ad.doubleclick.net/clk;262219671;13503038;y?
> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



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

------------------------------------------------------------------------------
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Mike,
	Thanks for the thread discussion and the profiling work.  I've been
walking this part of the code and your discussion fills in what I've been
forced to infer from rather sparsely documented c code.  High-level
discussions make a big difference in understanding why code is a certain
way.

	Not having Open Office, I tried reading your doc in Word 2010 which
complained as it converted it.  There is a big red "X" occupying all of page
three.  Everything else like text and profiler screen shots seem fine.  Is
the "X" really part of the original or did very much disappear through the
conversion between the end of the 4th paragraph in "Results" (...kperiod.)
and "I then used valgrind... which seems mid-paragraph?  I guess I could
look at the xml...  Or if you have Word, could you send a word version out
as well?

Thanks.

Richard Henninger

-----Original Message-----
From: Michael Gogins [mailto:michael.gogins@gmail.com] 
Sent: Monday, October 01, 2012 11:35 AM
To: Developer discussions
Subject: Re: [Cs-dev] Concurrency again

I think a test suite is a good idea. I would prefer it if there was a Python
test script that would use the subprocess module to run the tests and scape
stdout to determine results, with a config file to select tests; results
would then be written to a table in a text file that could be opened as a
spreadsheet. That said, this is a big piece of work and I'm not eager to
take it on... perhaps we could start with just multithreading and move other
tests in as they become important.

I don't understand why you think moving away from direct mixing is good, the
locking contention in all the concurrent designs seems a very small part of
the total threading overhead, it mostly seems to come from having too many
idling worker threads. But I could be wrong.
We may need to re-do the profiling with debug versions of the pthreads and
gomp libraries.

Best,
Mike


On Mon, Oct 1, 2012 at 11:12 AM, Steven Yi  wrote:
> Hi Michael,
>
> Thanks for the updated document and thoughts within it.  It seems we 
> still have a lot to experiment with, particularly work partitioning 
> strategies, and parallellism in series.  I imagine if we move direct 
> mixing to SPOUT out of the out opcodes, and modify to write to a local 
> spout and mix, we could do some interesting improvements (well, this 
> might go for all resources, to do delayed writing/mixing when 
> possible).
>
> Perhaps we should come up with a test suite of CSD's that illustrate 
> different scenarios?  Might be good to have some specific tests in 
> addition to the full-piece tests.
>
> Thanks!
> steven
>
> On Mon, Oct 1, 2012 at 4:41 AM, Michael Gogins 
wrote:
>> I attach a revised and, I think, much improved version of my paper on 
>> different versions of concurrent rendering in Csound.
>>
>> In particular, I have debugged the PARCS configuration and reviewed 
>> Wilson's thesis describing its design, so I think I have a much 
>> improved understanding of the PARCS design.
>>
>> I also was able to get the spinlocks version of the OpenMP design 
>> working and tested. Unfortunately, they didn't seem to help much.
>>
>> Please let me know your thoughts.
>>
>> Regards,
>> Mike
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>> ---------------------------------------------------------------------
>> ---------
>> Got visibility?
>> Most devs has no idea what their production app looks like.
>> Find out how fast your code is with AppDynamics Lite.
>> http://ad.doubleclick.net/clk;262219671;13503038;y?
>> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
> ----------------------------------------------------------------------
> --------
> Got visibility?
> Most devs has no idea what their production app looks like.
> Find out how fast your code is with AppDynamics Lite.
> http://ad.doubleclick.net/clk;262219671;13503038;y?
> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



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

----------------------------------------------------------------------------
--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

My pipe dream about unit testing for csound was always:

* expect (or a workalike) to test certain input to csound and
assertions regarding csound stderr output
* generation of audio files from applicable opcodes, with assertions
about certain properties of the fft bins, rms, etc. (of course you
would need a known good version of csound to run that test, or some
other trustworthy and programmable analytical tool, maybe a
mathematyical language like R or Octave could analyze the output
file).
* measure CPU time of csd's using certain opcodes, with warnings if
they are outside a configurable range performance wise

This is not to say I have the time to make such a thing myself any
time soon, but having a test framework with at least those three kinds
of metrics (regardless of implementation details) would be very useful
for keeping csound a bit more stable.

On Mon, Oct 1, 2012 at 8:35 AM, Michael Gogins  wrote:
> I think a test suite is a good idea. I would prefer it if there was a
> Python test script that would use the subprocess module to run the
> tests and scape stdout to determine results, with a config file to
> select tests; results would then be written to a table in a text file
> that could be opened as a spreadsheet. That said, this is a big piece
> of work and I'm not eager to take it on... perhaps we could start with
> just multithreading and move other tests in as they become important.
>
> I don't understand why you think moving away from direct mixing is
> good, the locking contention in all the concurrent designs seems a
> very small part of the total threading overhead, it mostly seems to
> come from having too many idling worker threads. But I could be wrong.
> We may need to re-do the profiling with debug versions of the pthreads
> and gomp libraries.
>
> Best,
> Mike
>
>
> On Mon, Oct 1, 2012 at 11:12 AM, Steven Yi  wrote:
>> Hi Michael,
>>
>> Thanks for the updated document and thoughts within it.  It seems we
>> still have a lot to experiment with, particularly work partitioning
>> strategies, and parallellism in series.  I imagine if we move direct
>> mixing to SPOUT out of the out opcodes, and modify to write to a local
>> spout and mix, we could do some interesting improvements (well, this
>> might go for all resources, to do delayed writing/mixing when
>> possible).
>>
>> Perhaps we should come up with a test suite of CSD's that illustrate
>> different scenarios?  Might be good to have some specific tests in
>> addition to the full-piece tests.
>>
>> Thanks!
>> steven
>>
>> On Mon, Oct 1, 2012 at 4:41 AM, Michael Gogins  wrote:
>>> I attach a revised and, I think, much improved version of my paper on
>>> different versions of concurrent rendering in Csound.
>>>
>>> In particular, I have debugged the PARCS configuration and reviewed
>>> Wilson's thesis describing its design, so I think I have a much
>>> improved understanding of the PARCS design.
>>>
>>> I also was able to get the spinlocks version of the OpenMP design
>>> working and tested. Unfortunately, they didn't seem to help much.
>>>
>>> Please let me know your thoughts.
>>>
>>> Regards,
>>> Mike
>>>
>>> --
>>> Michael Gogins
>>> Irreducible Productions
>>> http://www.michael-gogins.com
>>> Michael dot Gogins at gmail dot com
>>>
>>> ------------------------------------------------------------------------------
>>> Got visibility?
>>> Most devs has no idea what their production app looks like.
>>> Find out how fast your code is with AppDynamics Lite.
>>> http://ad.doubleclick.net/clk;262219671;13503038;y?
>>> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>> ------------------------------------------------------------------------------
>> Got visibility?
>> Most devs has no idea what their production app looks like.
>> Find out how fast your code is with AppDynamics Lite.
>> http://ad.doubleclick.net/clk;262219671;13503038;y?
>> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
> ------------------------------------------------------------------------------
> Got visibility?
> Most devs has no idea what their production app looks like.
> Find out how fast your code is with AppDynamics Lite.
> http://ad.doubleclick.net/clk;262219671;13503038;y?
> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net