I've attached a report of a study I've made of parallel Csound.
Comments and corrections are welcome. I'd particularly like to hear
thoughts about jpff's new approach to threading, or to possible
improvements in the PARCS branch.

Regards,
Mike

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

Hi Michael,

Thanks for sharing this, I think it's very important.  Do you think
then we should remove the OPENMP code in the Csound codebase? (I'd
like to see csound6's codebase remove all of the dead code possible.)

Also, did you use a driving program to do timing? I was thinking it
would be nice to have a sort of multicore testing program we could
collectively share in using during development, such that we could
just call "make testMultiCore" to build/run it.

Thanks!
steven

On Sun, Sep 23, 2012 at 3:05 AM, Michael Gogins
 wrote:
> I've attached a report of a study I've made of parallel Csound.
> Comments and corrections are welcome. I'd particularly like to hear
> thoughts about jpff's new approach to threading, or to possible
> improvements in the PARCS branch.
>
> Regards,
> Mike
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://ad.doubleclick.net/clk;258768047;13503038;j?
> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://ad.doubleclick.net/clk;258768047;13503038;j?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I didn't use one, but I think a real test suite would be an excellent
idea for Csound. It should save test results in a tabular format, and
it should provide options for running different sets of tests.

I'm not sure about the USE_OPENMP code yet. I don't fully understand
my own test results. I'd like to continue looking into this. I
understand how the USE_OPENMP code works, but I don't completely
understand the PARCS code yet. The USE_OPENMP code is slower than the
PARCS code for trapped-high-resolution.csd, but I'm not really sure
why. I'd like to be sure before we take out a body of working code. It
is faster than PARCS for CloudStrata.csd, after all.

I'm wondering if, once I really understand the PARCS code, there isn't
some third possibility. One thing I've already thought about is using
spinlocks for the USE_OPENMP design (currently it seems that the
OpenMP critical sections use mutexes, not spinlocks). The PARCS code
already uses spinlocks. The USE_OPENMP code used to use spinlocks, but
somebody disabled them, perhaps as an unintended side effect of
working on the PARCS code.

So, what I'm going to be doing is trying to understand the PARCS code
in depth on the one hand, and trying to improve the USE_OPENMP code on
the other hand.

I have a gut feeling that there's another 50% to 100% speedup if we
really dot all our is and cross all our ts.

I agree that this kind of work is very important. This is an area
where Csound can really forge ahead and give a lot more power to
musicians.

Best,
Mike


On Sun, Sep 23, 2012 at 7:17 AM, Steven Yi  wrote:
> Hi Michael,
>
> Thanks for sharing this, I think it's very important.  Do you think
> then we should remove the OPENMP code in the Csound codebase? (I'd
> like to see csound6's codebase remove all of the dead code possible.)
>
> Also, did you use a driving program to do timing? I was thinking it
> would be nice to have a sort of multicore testing program we could
> collectively share in using during development, such that we could
> just call "make testMultiCore" to build/run it.
>
> Thanks!
> steven
>
> On Sun, Sep 23, 2012 at 3:05 AM, Michael Gogins
>  wrote:
>> I've attached a report of a study I've made of parallel Csound.
>> Comments and corrections are welcome. I'd particularly like to hear
>> thoughts about jpff's new approach to threading, or to possible
>> improvements in the PARCS branch.
>>
>> Regards,
>> Mike
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://ad.doubleclick.net/clk;258768047;13503038;j?
>> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://ad.doubleclick.net/clk;258768047;13503038;j?
> 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

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://ad.doubleclick.net/clk;258768047;13503038;j?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Apologies if my vague understanding of the issue leads to
nonintelligent questions,
but I still hope my 2cents can be relevant.
It seems that the USE_OPENMP method of splitting concurrently running
instances of the same instrument may be a good thing to keep until
testing on a broader range of orchestras have been done.
Such testing may *perhaps* only happen when more of us start using
parallel processing for daily work in Csound.

Also one thing that I have yet to understand is if the locks on hidden
globals (chn, zak etc) implies that for example:
- any write or read of a chn channel locks this part of the code from
being parallelized
(that was a question)
.. if so it seems that many locks would happen in situations where
they are not needed(?)
I fully realize that it is a complex task to determine if the use a
hidden global needs to be locked from parallelization or not,
and perhaps there are more going on behind the scenes that I have
understood in terms of determining what to lock and not.
As a means of development and testing, would it be a good idea (as I
think have been raised before) to have "manual parallelization"
opcodes to mark sections of code that must be locked and sections that
explicitly can be parallelized? I know this can lead to a substantial
amount of errors due to user error, and should definitely be marked as
"experimental" and "use on your own risk", but they could shed some
additional light on situations where parallelization can be effective
and also a more explicit means of testing parallelization for
different use cases

best
Oeyvind

2012/9/23 Michael Gogins :
> I didn't use one, but I think a real test suite would be an excellent
> idea for Csound. It should save test results in a tabular format, and
> it should provide options for running different sets of tests.
>
> I'm not sure about the USE_OPENMP code yet. I don't fully understand
> my own test results. I'd like to continue looking into this. I
> understand how the USE_OPENMP code works, but I don't completely
> understand the PARCS code yet. The USE_OPENMP code is slower than the
> PARCS code for trapped-high-resolution.csd, but I'm not really sure
> why. I'd like to be sure before we take out a body of working code. It
> is faster than PARCS for CloudStrata.csd, after all.
>
> I'm wondering if, once I really understand the PARCS code, there isn't
> some third possibility. One thing I've already thought about is using
> spinlocks for the USE_OPENMP design (currently it seems that the
> OpenMP critical sections use mutexes, not spinlocks). The PARCS code
> already uses spinlocks. The USE_OPENMP code used to use spinlocks, but
> somebody disabled them, perhaps as an unintended side effect of
> working on the PARCS code.
>
> So, what I'm going to be doing is trying to understand the PARCS code
> in depth on the one hand, and trying to improve the USE_OPENMP code on
> the other hand.
>
> I have a gut feeling that there's another 50% to 100% speedup if we
> really dot all our is and cross all our ts.
>
> I agree that this kind of work is very important. This is an area
> where Csound can really forge ahead and give a lot more power to
> musicians.
>
> Best,
> Mike
>
>
> On Sun, Sep 23, 2012 at 7:17 AM, Steven Yi  wrote:
>> Hi Michael,
>>
>> Thanks for sharing this, I think it's very important.  Do you think
>> then we should remove the OPENMP code in the Csound codebase? (I'd
>> like to see csound6's codebase remove all of the dead code possible.)
>>
>> Also, did you use a driving program to do timing? I was thinking it
>> would be nice to have a sort of multicore testing program we could
>> collectively share in using during development, such that we could
>> just call "make testMultiCore" to build/run it.
>>
>> Thanks!
>> steven
>>
>> On Sun, Sep 23, 2012 at 3:05 AM, Michael Gogins
>>  wrote:
>>> I've attached a report of a study I've made of parallel Csound.
>>> Comments and corrections are welcome. I'd particularly like to hear
>>> thoughts about jpff's new approach to threading, or to possible
>>> improvements in the PARCS branch.
>>>
>>> Regards,
>>> Mike
>>>
>>> --
>>> Michael Gogins
>>> Irreducible Productions
>>> http://www.michael-gogins.com
>>> Michael dot Gogins at gmail dot com
>>>
>>> ------------------------------------------------------------------------------
>>> Everyone hates slow websites. So do we.
>>> Make your web apps faster with AppDynamics
>>> Download AppDynamics Lite for free today:
>>> http://ad.doubleclick.net/clk;258768047;13503038;j?
>>> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://ad.doubleclick.net/clk;258768047;13503038;j?
>> 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
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://ad.doubleclick.net/clk;258768047;13503038;j?
> 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

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://ad.doubleclick.net/clk;258768047;13503038;j?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

An even bigger deal is that tables are global. Tables get used much
more than zak or chan or even g* variables, and while most opcodes can
be used without zak/chan/g*, many opcodes only work with tables. The
code containing these things can be parallelized, but needs to be
synchronized between the threads when it hits output to these objects
before any reads of said objects occur in another thread. The fewer
synchronizations, the more advantage gained from the parallelization.

On Sun, Sep 23, 2012 at 2:48 PM, Oeyvind Brandtsegg
 wrote:
> Apologies if my vague understanding of the issue leads to
> nonintelligent questions,
> but I still hope my 2cents can be relevant.
> It seems that the USE_OPENMP method of splitting concurrently running
> instances of the same instrument may be a good thing to keep until
> testing on a broader range of orchestras have been done.
> Such testing may *perhaps* only happen when more of us start using
> parallel processing for daily work in Csound.
>
> Also one thing that I have yet to understand is if the locks on hidden
> globals (chn, zak etc) implies that for example:
> - any write or read of a chn channel locks this part of the code from
> being parallelized
> (that was a question)
> .. if so it seems that many locks would happen in situations where
> they are not needed(?)
> I fully realize that it is a complex task to determine if the use a
> hidden global needs to be locked from parallelization or not,
> and perhaps there are more going on behind the scenes that I have
> understood in terms of determining what to lock and not.
> As a means of development and testing, would it be a good idea (as I
> think have been raised before) to have "manual parallelization"
> opcodes to mark sections of code that must be locked and sections that
> explicitly can be parallelized? I know this can lead to a substantial
> amount of errors due to user error, and should definitely be marked as
> "experimental" and "use on your own risk", but they could shed some
> additional light on situations where parallelization can be effective
> and also a more explicit means of testing parallelization for
> different use cases
>
> best
> Oeyvind
>
> 2012/9/23 Michael Gogins :
>> I didn't use one, but I think a real test suite would be an excellent
>> idea for Csound. It should save test results in a tabular format, and
>> it should provide options for running different sets of tests.
>>
>> I'm not sure about the USE_OPENMP code yet. I don't fully understand
>> my own test results. I'd like to continue looking into this. I
>> understand how the USE_OPENMP code works, but I don't completely
>> understand the PARCS code yet. The USE_OPENMP code is slower than the
>> PARCS code for trapped-high-resolution.csd, but I'm not really sure
>> why. I'd like to be sure before we take out a body of working code. It
>> is faster than PARCS for CloudStrata.csd, after all.
>>
>> I'm wondering if, once I really understand the PARCS code, there isn't
>> some third possibility. One thing I've already thought about is using
>> spinlocks for the USE_OPENMP design (currently it seems that the
>> OpenMP critical sections use mutexes, not spinlocks). The PARCS code
>> already uses spinlocks. The USE_OPENMP code used to use spinlocks, but
>> somebody disabled them, perhaps as an unintended side effect of
>> working on the PARCS code.
>>
>> So, what I'm going to be doing is trying to understand the PARCS code
>> in depth on the one hand, and trying to improve the USE_OPENMP code on
>> the other hand.
>>
>> I have a gut feeling that there's another 50% to 100% speedup if we
>> really dot all our is and cross all our ts.
>>
>> I agree that this kind of work is very important. This is an area
>> where Csound can really forge ahead and give a lot more power to
>> musicians.
>>
>> Best,
>> Mike
>>
>>
>> On Sun, Sep 23, 2012 at 7:17 AM, Steven Yi  wrote:
>>> Hi Michael,
>>>
>>> Thanks for sharing this, I think it's very important.  Do you think
>>> then we should remove the OPENMP code in the Csound codebase? (I'd
>>> like to see csound6's codebase remove all of the dead code possible.)
>>>
>>> Also, did you use a driving program to do timing? I was thinking it
>>> would be nice to have a sort of multicore testing program we could
>>> collectively share in using during development, such that we could
>>> just call "make testMultiCore" to build/run it.
>>>
>>> Thanks!
>>> steven
>>>
>>> On Sun, Sep 23, 2012 at 3:05 AM, Michael Gogins
>>>  wrote:
>>>> I've attached a report of a study I've made of parallel Csound.
>>>> Comments and corrections are welcome. I'd particularly like to hear
>>>> thoughts about jpff's new approach to threading, or to possible
>>>> improvements in the PARCS branch.
>>>>
>>>> Regards,
>>>> Mike
>>>>
>>>> --
>>>> Michael Gogins
>>>> Irreducible Productions
>>>> http://www.michael-gogins.com
>>>> Michael dot Gogins at gmail dot com
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Everyone hates slow websites. So do we.
>>>> Make your web apps faster with AppDynamics
>>>> Download AppDynamics Lite for free today:
>>>> http://ad.doubleclick.net/clk;258768047;13503038;j?
>>>> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Everyone hates slow websites. So do we.
>>> Make your web apps faster with AppDynamics
>>> Download AppDynamics Lite for free today:
>>> http://ad.doubleclick.net/clk;258768047;13503038;j?
>>> 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
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://ad.doubleclick.net/clk;258768047;13503038;j?
>> 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
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://ad.doubleclick.net/clk;258768047;13503038;j?
> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://ad.doubleclick.net/clk;258768047;13503038;j?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

agreed,
and my main concern was if a lock related to table read/write will
occur in *all cases* where a read or write is implied,
or if we only lock when the read/write occurs to *the same table*?
Oeyvind

2012/9/23 Justin Smith :
> An even bigger deal is that tables are global. Tables get used much
> more than zak or chan or even g* variables, and while most opcodes can
> be used without zak/chan/g*, many opcodes only work with tables. The
> code containing these things can be parallelized, but needs to be
> synchronized between the threads when it hits output to these objects
> before any reads of said objects occur in another thread. The fewer
> synchronizations, the more advantage gained from the parallelization.
>
> On Sun, Sep 23, 2012 at 2:48 PM, Oeyvind Brandtsegg
>  wrote:
>> Apologies if my vague understanding of the issue leads to
>> nonintelligent questions,
>> but I still hope my 2cents can be relevant.
>> It seems that the USE_OPENMP method of splitting concurrently running
>> instances of the same instrument may be a good thing to keep until
>> testing on a broader range of orchestras have been done.
>> Such testing may *perhaps* only happen when more of us start using
>> parallel processing for daily work in Csound.
>>
>> Also one thing that I have yet to understand is if the locks on hidden
>> globals (chn, zak etc) implies that for example:
>> - any write or read of a chn channel locks this part of the code from
>> being parallelized
>> (that was a question)
>> .. if so it seems that many locks would happen in situations where
>> they are not needed(?)
>> I fully realize that it is a complex task to determine if the use a
>> hidden global needs to be locked from parallelization or not,
>> and perhaps there are more going on behind the scenes that I have
>> understood in terms of determining what to lock and not.
>> As a means of development and testing, would it be a good idea (as I
>> think have been raised before) to have "manual parallelization"
>> opcodes to mark sections of code that must be locked and sections that
>> explicitly can be parallelized? I know this can lead to a substantial
>> amount of errors due to user error, and should definitely be marked as
>> "experimental" and "use on your own risk", but they could shed some
>> additional light on situations where parallelization can be effective
>> and also a more explicit means of testing parallelization for
>> different use cases
>>
>> best
>> Oeyvind
>>
>> 2012/9/23 Michael Gogins :
>>> I didn't use one, but I think a real test suite would be an excellent
>>> idea for Csound. It should save test results in a tabular format, and
>>> it should provide options for running different sets of tests.
>>>
>>> I'm not sure about the USE_OPENMP code yet. I don't fully understand
>>> my own test results. I'd like to continue looking into this. I
>>> understand how the USE_OPENMP code works, but I don't completely
>>> understand the PARCS code yet. The USE_OPENMP code is slower than the
>>> PARCS code for trapped-high-resolution.csd, but I'm not really sure
>>> why. I'd like to be sure before we take out a body of working code. It
>>> is faster than PARCS for CloudStrata.csd, after all.
>>>
>>> I'm wondering if, once I really understand the PARCS code, there isn't
>>> some third possibility. One thing I've already thought about is using
>>> spinlocks for the USE_OPENMP design (currently it seems that the
>>> OpenMP critical sections use mutexes, not spinlocks). The PARCS code
>>> already uses spinlocks. The USE_OPENMP code used to use spinlocks, but
>>> somebody disabled them, perhaps as an unintended side effect of
>>> working on the PARCS code.
>>>
>>> So, what I'm going to be doing is trying to understand the PARCS code
>>> in depth on the one hand, and trying to improve the USE_OPENMP code on
>>> the other hand.
>>>
>>> I have a gut feeling that there's another 50% to 100% speedup if we
>>> really dot all our is and cross all our ts.
>>>
>>> I agree that this kind of work is very important. This is an area
>>> where Csound can really forge ahead and give a lot more power to
>>> musicians.
>>>
>>> Best,
>>> Mike
>>>
>>>
>>> On Sun, Sep 23, 2012 at 7:17 AM, Steven Yi  wrote:
>>>> Hi Michael,
>>>>
>>>> Thanks for sharing this, I think it's very important.  Do you think
>>>> then we should remove the OPENMP code in the Csound codebase? (I'd
>>>> like to see csound6's codebase remove all of the dead code possible.)
>>>>
>>>> Also, did you use a driving program to do timing? I was thinking it
>>>> would be nice to have a sort of multicore testing program we could
>>>> collectively share in using during development, such that we could
>>>> just call "make testMultiCore" to build/run it.
>>>>
>>>> Thanks!
>>>> steven
>>>>
>>>> On Sun, Sep 23, 2012 at 3:05 AM, Michael Gogins
>>>>  wrote:
>>>>> I've attached a report of a study I've made of parallel Csound.
>>>>> Comments and corrections are welcome. I'd particularly like to hear
>>>>> thoughts about jpff's new approach to threading, or to possible
>>>>> improvements in the PARCS branch.
>>>>>
>>>>> Regards,
>>>>> Mike
>>>>>
>>>>> --
>>>>> Michael Gogins
>>>>> Irreducible Productions
>>>>> http://www.michael-gogins.com
>>>>> Michael dot Gogins at gmail dot com
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Everyone hates slow websites. So do we.
>>>>> Make your web apps faster with AppDynamics
>>>>> Download AppDynamics Lite for free today:
>>>>> http://ad.doubleclick.net/clk;258768047;13503038;j?
>>>>> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Everyone hates slow websites. So do we.
>>>> Make your web apps faster with AppDynamics
>>>> Download AppDynamics Lite for free today:
>>>> http://ad.doubleclick.net/clk;258768047;13503038;j?
>>>> 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
>>>
>>> ------------------------------------------------------------------------------
>>> Everyone hates slow websites. So do we.
>>> Make your web apps faster with AppDynamics
>>> Download AppDynamics Lite for free today:
>>> http://ad.doubleclick.net/clk;258768047;13503038;j?
>>> 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
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://ad.doubleclick.net/clk;258768047;13503038;j?
>> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://ad.doubleclick.net/clk;258768047;13503038;j?
> 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

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://ad.doubleclick.net/clk;258768047;13503038;j?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

The original multicore implementation I had done had manual locking
(the mutex opcodes are still included in csound). It required user
coding to mark what was locked and when.  Automatic parallelization
was then done with PARCS.

I think we haven't collectively had a real chance to focus on
multicore really.  It seems to me though that the automatic solutions
still have a lot of possibilities to improve and are worth focusing on
over manual solutions at this time.

On Sun, Sep 23, 2012 at 11:48 PM, Oeyvind Brandtsegg
 wrote:
> Apologies if my vague understanding of the issue leads to
> nonintelligent questions,
> but I still hope my 2cents can be relevant.
> It seems that the USE_OPENMP method of splitting concurrently running
> instances of the same instrument may be a good thing to keep until
> testing on a broader range of orchestras have been done.
> Such testing may *perhaps* only happen when more of us start using
> parallel processing for daily work in Csound.
>
> Also one thing that I have yet to understand is if the locks on hidden
> globals (chn, zak etc) implies that for example:
> - any write or read of a chn channel locks this part of the code from
> being parallelized
> (that was a question)
> .. if so it seems that many locks would happen in situations where
> they are not needed(?)
> I fully realize that it is a complex task to determine if the use a
> hidden global needs to be locked from parallelization or not,
> and perhaps there are more going on behind the scenes that I have
> understood in terms of determining what to lock and not.
> As a means of development and testing, would it be a good idea (as I
> think have been raised before) to have "manual parallelization"
> opcodes to mark sections of code that must be locked and sections that
> explicitly can be parallelized? I know this can lead to a substantial
> amount of errors due to user error, and should definitely be marked as
> "experimental" and "use on your own risk", but they could shed some
> additional light on situations where parallelization can be effective
> and also a more explicit means of testing parallelization for
> different use cases
>
> best
> Oeyvind
>
> 2012/9/23 Michael Gogins :
>> I didn't use one, but I think a real test suite would be an excellent
>> idea for Csound. It should save test results in a tabular format, and
>> it should provide options for running different sets of tests.
>>
>> I'm not sure about the USE_OPENMP code yet. I don't fully understand
>> my own test results. I'd like to continue looking into this. I
>> understand how the USE_OPENMP code works, but I don't completely
>> understand the PARCS code yet. The USE_OPENMP code is slower than the
>> PARCS code for trapped-high-resolution.csd, but I'm not really sure
>> why. I'd like to be sure before we take out a body of working code. It
>> is faster than PARCS for CloudStrata.csd, after all.
>>
>> I'm wondering if, once I really understand the PARCS code, there isn't
>> some third possibility. One thing I've already thought about is using
>> spinlocks for the USE_OPENMP design (currently it seems that the
>> OpenMP critical sections use mutexes, not spinlocks). The PARCS code
>> already uses spinlocks. The USE_OPENMP code used to use spinlocks, but
>> somebody disabled them, perhaps as an unintended side effect of
>> working on the PARCS code.
>>
>> So, what I'm going to be doing is trying to understand the PARCS code
>> in depth on the one hand, and trying to improve the USE_OPENMP code on
>> the other hand.
>>
>> I have a gut feeling that there's another 50% to 100% speedup if we
>> really dot all our is and cross all our ts.
>>
>> I agree that this kind of work is very important. This is an area
>> where Csound can really forge ahead and give a lot more power to
>> musicians.
>>
>> Best,
>> Mike
>>
>>
>> On Sun, Sep 23, 2012 at 7:17 AM, Steven Yi  wrote:
>>> Hi Michael,
>>>
>>> Thanks for sharing this, I think it's very important.  Do you think
>>> then we should remove the OPENMP code in the Csound codebase? (I'd
>>> like to see csound6's codebase remove all of the dead code possible.)
>>>
>>> Also, did you use a driving program to do timing? I was thinking it
>>> would be nice to have a sort of multicore testing program we could
>>> collectively share in using during development, such that we could
>>> just call "make testMultiCore" to build/run it.
>>>
>>> Thanks!
>>> steven
>>>
>>> On Sun, Sep 23, 2012 at 3:05 AM, Michael Gogins
>>>  wrote:
>>>> I've attached a report of a study I've made of parallel Csound.
>>>> Comments and corrections are welcome. I'd particularly like to hear
>>>> thoughts about jpff's new approach to threading, or to possible
>>>> improvements in the PARCS branch.
>>>>
>>>> Regards,
>>>> Mike
>>>>
>>>> --
>>>> Michael Gogins
>>>> Irreducible Productions
>>>> http://www.michael-gogins.com
>>>> Michael dot Gogins at gmail dot com
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Everyone hates slow websites. So do we.
>>>> Make your web apps faster with AppDynamics
>>>> Download AppDynamics Lite for free today:
>>>> http://ad.doubleclick.net/clk;258768047;13503038;j?
>>>> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Everyone hates slow websites. So do we.
>>> Make your web apps faster with AppDynamics
>>> Download AppDynamics Lite for free today:
>>> http://ad.doubleclick.net/clk;258768047;13503038;j?
>>> 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
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://ad.doubleclick.net/clk;258768047;13503038;j?
>> 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
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://ad.doubleclick.net/clk;258768047;13503038;j?
> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://ad.doubleclick.net/clk;258768047;13503038;j?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Actually I think there are three concepts at work here:

(1) PARCS which analyses the whole data flow graph and decomposes it
and locks, by jpff and his student and maybe others.

(2) Steven Yi's which uses barriers to create tasks in the krate loop,
then provides facilities for users to explicitly lock potential data
races.

(2) USE_OPENMP which is my variant of Yi's approach, it just applies
an OpenMP task to the krate loop, and puts in spinlocks on potential
data races. This is based on the assumption that spinlocks are cheap,
I read they are several times faster than mutexes.

Currently, the USE_OPENMP spinlocks are not working, I am trying to
get them back. I am also trying to understand the PARCS code well
enough to perhaps optimize it, though it may already be optimal - I
don't know yet.

Regards,
Mike

On Sun, Sep 23, 2012 at 6:59 PM, Steven Yi  wrote:
> The original multicore implementation I had done had manual locking
> (the mutex opcodes are still included in csound). It required user
> coding to mark what was locked and when.  Automatic parallelization
> was then done with PARCS.
>
> I think we haven't collectively had a real chance to focus on
> multicore really.  It seems to me though that the automatic solutions
> still have a lot of possibilities to improve and are worth focusing on
> over manual solutions at this time.
>
> On Sun, Sep 23, 2012 at 11:48 PM, Oeyvind Brandtsegg
>  wrote:
>> Apologies if my vague understanding of the issue leads to
>> nonintelligent questions,
>> but I still hope my 2cents can be relevant.
>> It seems that the USE_OPENMP method of splitting concurrently running
>> instances of the same instrument may be a good thing to keep until
>> testing on a broader range of orchestras have been done.
>> Such testing may *perhaps* only happen when more of us start using
>> parallel processing for daily work in Csound.
>>
>> Also one thing that I have yet to understand is if the locks on hidden
>> globals (chn, zak etc) implies that for example:
>> - any write or read of a chn channel locks this part of the code from
>> being parallelized
>> (that was a question)
>> .. if so it seems that many locks would happen in situations where
>> they are not needed(?)
>> I fully realize that it is a complex task to determine if the use a
>> hidden global needs to be locked from parallelization or not,
>> and perhaps there are more going on behind the scenes that I have
>> understood in terms of determining what to lock and not.
>> As a means of development and testing, would it be a good idea (as I
>> think have been raised before) to have "manual parallelization"
>> opcodes to mark sections of code that must be locked and sections that
>> explicitly can be parallelized? I know this can lead to a substantial
>> amount of errors due to user error, and should definitely be marked as
>> "experimental" and "use on your own risk", but they could shed some
>> additional light on situations where parallelization can be effective
>> and also a more explicit means of testing parallelization for
>> different use cases
>>
>> best
>> Oeyvind
>>
>> 2012/9/23 Michael Gogins :
>>> I didn't use one, but I think a real test suite would be an excellent
>>> idea for Csound. It should save test results in a tabular format, and
>>> it should provide options for running different sets of tests.
>>>
>>> I'm not sure about the USE_OPENMP code yet. I don't fully understand
>>> my own test results. I'd like to continue looking into this. I
>>> understand how the USE_OPENMP code works, but I don't completely
>>> understand the PARCS code yet. The USE_OPENMP code is slower than the
>>> PARCS code for trapped-high-resolution.csd, but I'm not really sure
>>> why. I'd like to be sure before we take out a body of working code. It
>>> is faster than PARCS for CloudStrata.csd, after all.
>>>
>>> I'm wondering if, once I really understand the PARCS code, there isn't
>>> some third possibility. One thing I've already thought about is using
>>> spinlocks for the USE_OPENMP design (currently it seems that the
>>> OpenMP critical sections use mutexes, not spinlocks). The PARCS code
>>> already uses spinlocks. The USE_OPENMP code used to use spinlocks, but
>>> somebody disabled them, perhaps as an unintended side effect of
>>> working on the PARCS code.
>>>
>>> So, what I'm going to be doing is trying to understand the PARCS code
>>> in depth on the one hand, and trying to improve the USE_OPENMP code on
>>> the other hand.
>>>
>>> I have a gut feeling that there's another 50% to 100% speedup if we
>>> really dot all our is and cross all our ts.
>>>
>>> I agree that this kind of work is very important. This is an area
>>> where Csound can really forge ahead and give a lot more power to
>>> musicians.
>>>
>>> Best,
>>> Mike
>>>
>>>
>>> On Sun, Sep 23, 2012 at 7:17 AM, Steven Yi  wrote:
>>>> Hi Michael,
>>>>
>>>> Thanks for sharing this, I think it's very important.  Do you think
>>>> then we should remove the OPENMP code in the Csound codebase? (I'd
>>>> like to see csound6's codebase remove all of the dead code possible.)
>>>>
>>>> Also, did you use a driving program to do timing? I was thinking it
>>>> would be nice to have a sort of multicore testing program we could
>>>> collectively share in using during development, such that we could
>>>> just call "make testMultiCore" to build/run it.
>>>>
>>>> Thanks!
>>>> steven
>>>>
>>>> On Sun, Sep 23, 2012 at 3:05 AM, Michael Gogins
>>>>  wrote:
>>>>> I've attached a report of a study I've made of parallel Csound.
>>>>> Comments and corrections are welcome. I'd particularly like to hear
>>>>> thoughts about jpff's new approach to threading, or to possible
>>>>> improvements in the PARCS branch.
>>>>>
>>>>> Regards,
>>>>> Mike
>>>>>
>>>>> --
>>>>> Michael Gogins
>>>>> Irreducible Productions
>>>>> http://www.michael-gogins.com
>>>>> Michael dot Gogins at gmail dot com
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Everyone hates slow websites. So do we.
>>>>> Make your web apps faster with AppDynamics
>>>>> Download AppDynamics Lite for free today:
>>>>> http://ad.doubleclick.net/clk;258768047;13503038;j?
>>>>> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Everyone hates slow websites. So do we.
>>>> Make your web apps faster with AppDynamics
>>>> Download AppDynamics Lite for free today:
>>>> http://ad.doubleclick.net/clk;258768047;13503038;j?
>>>> 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
>>>
>>> ------------------------------------------------------------------------------
>>> Everyone hates slow websites. So do we.
>>> Make your web apps faster with AppDynamics
>>> Download AppDynamics Lite for free today:
>>> http://ad.doubleclick.net/clk;258768047;13503038;j?
>>> 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
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://ad.doubleclick.net/clk;258768047;13503038;j?
>> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://ad.doubleclick.net/clk;258768047;13503038;j?
> 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

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

We are aware of many places where synchronization to avoid data races
will be required.

I don't think we've yet done enough testing and experiment to
determine a best approach. I like the thinking in the PARCS design but
it doesn't "feel" fast enough. I have a certain amount of professional
experience with multithreading, but not with such complex code, so my
intuition may be off.

Regards,
Mike

On Sun, Sep 23, 2012 at 5:59 PM, Justin Smith  wrote:
> An even bigger deal is that tables are global. Tables get used much
> more than zak or chan or even g* variables, and while most opcodes can
> be used without zak/chan/g*, many opcodes only work with tables. The
> code containing these things can be parallelized, but needs to be
> synchronized between the threads when it hits output to these objects
> before any reads of said objects occur in another thread. The fewer
> synchronizations, the more advantage gained from the parallelization.
>
> On Sun, Sep 23, 2012 at 2:48 PM, Oeyvind Brandtsegg
>  wrote:
>> Apologies if my vague understanding of the issue leads to
>> nonintelligent questions,
>> but I still hope my 2cents can be relevant.
>> It seems that the USE_OPENMP method of splitting concurrently running
>> instances of the same instrument may be a good thing to keep until
>> testing on a broader range of orchestras have been done.
>> Such testing may *perhaps* only happen when more of us start using
>> parallel processing for daily work in Csound.
>>
>> Also one thing that I have yet to understand is if the locks on hidden
>> globals (chn, zak etc) implies that for example:
>> - any write or read of a chn channel locks this part of the code from
>> being parallelized
>> (that was a question)
>> .. if so it seems that many locks would happen in situations where
>> they are not needed(?)
>> I fully realize that it is a complex task to determine if the use a
>> hidden global needs to be locked from parallelization or not,
>> and perhaps there are more going on behind the scenes that I have
>> understood in terms of determining what to lock and not.
>> As a means of development and testing, would it be a good idea (as I
>> think have been raised before) to have "manual parallelization"
>> opcodes to mark sections of code that must be locked and sections that
>> explicitly can be parallelized? I know this can lead to a substantial
>> amount of errors due to user error, and should definitely be marked as
>> "experimental" and "use on your own risk", but they could shed some
>> additional light on situations where parallelization can be effective
>> and also a more explicit means of testing parallelization for
>> different use cases
>>
>> best
>> Oeyvind
>>
>> 2012/9/23 Michael Gogins :
>>> I didn't use one, but I think a real test suite would be an excellent
>>> idea for Csound. It should save test results in a tabular format, and
>>> it should provide options for running different sets of tests.
>>>
>>> I'm not sure about the USE_OPENMP code yet. I don't fully understand
>>> my own test results. I'd like to continue looking into this. I
>>> understand how the USE_OPENMP code works, but I don't completely
>>> understand the PARCS code yet. The USE_OPENMP code is slower than the
>>> PARCS code for trapped-high-resolution.csd, but I'm not really sure
>>> why. I'd like to be sure before we take out a body of working code. It
>>> is faster than PARCS for CloudStrata.csd, after all.
>>>
>>> I'm wondering if, once I really understand the PARCS code, there isn't
>>> some third possibility. One thing I've already thought about is using
>>> spinlocks for the USE_OPENMP design (currently it seems that the
>>> OpenMP critical sections use mutexes, not spinlocks). The PARCS code
>>> already uses spinlocks. The USE_OPENMP code used to use spinlocks, but
>>> somebody disabled them, perhaps as an unintended side effect of
>>> working on the PARCS code.
>>>
>>> So, what I'm going to be doing is trying to understand the PARCS code
>>> in depth on the one hand, and trying to improve the USE_OPENMP code on
>>> the other hand.
>>>
>>> I have a gut feeling that there's another 50% to 100% speedup if we
>>> really dot all our is and cross all our ts.
>>>
>>> I agree that this kind of work is very important. This is an area
>>> where Csound can really forge ahead and give a lot more power to
>>> musicians.
>>>
>>> Best,
>>> Mike
>>>
>>>
>>> On Sun, Sep 23, 2012 at 7:17 AM, Steven Yi  wrote:
>>>> Hi Michael,
>>>>
>>>> Thanks for sharing this, I think it's very important.  Do you think
>>>> then we should remove the OPENMP code in the Csound codebase? (I'd
>>>> like to see csound6's codebase remove all of the dead code possible.)
>>>>
>>>> Also, did you use a driving program to do timing? I was thinking it
>>>> would be nice to have a sort of multicore testing program we could
>>>> collectively share in using during development, such that we could
>>>> just call "make testMultiCore" to build/run it.
>>>>
>>>> Thanks!
>>>> steven
>>>>
>>>> On Sun, Sep 23, 2012 at 3:05 AM, Michael Gogins
>>>>  wrote:
>>>>> I've attached a report of a study I've made of parallel Csound.
>>>>> Comments and corrections are welcome. I'd particularly like to hear
>>>>> thoughts about jpff's new approach to threading, or to possible
>>>>> improvements in the PARCS branch.
>>>>>
>>>>> Regards,
>>>>> Mike
>>>>>
>>>>> --
>>>>> Michael Gogins
>>>>> Irreducible Productions
>>>>> http://www.michael-gogins.com
>>>>> Michael dot Gogins at gmail dot com
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Everyone hates slow websites. So do we.
>>>>> Make your web apps faster with AppDynamics
>>>>> Download AppDynamics Lite for free today:
>>>>> http://ad.doubleclick.net/clk;258768047;13503038;j?
>>>>> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Everyone hates slow websites. So do we.
>>>> Make your web apps faster with AppDynamics
>>>> Download AppDynamics Lite for free today:
>>>> http://ad.doubleclick.net/clk;258768047;13503038;j?
>>>> 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
>>>
>>> ------------------------------------------------------------------------------
>>> Everyone hates slow websites. So do we.
>>> Make your web apps faster with AppDynamics
>>> Download AppDynamics Lite for free today:
>>> http://ad.doubleclick.net/clk;258768047;13503038;j?
>>> 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
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://ad.doubleclick.net/clk;258768047;13503038;j?
>> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://ad.doubleclick.net/clk;258768047;13503038;j?
> 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

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net