What consequences would changing the size of ksmps between calls to
csoundPerformKsmps have on things? I just tried a simple test there
and didn't notice any problems. I added a csoundSetKsmps() method to
the API and ran the example below with both real-time input/output and
straight synthesis examples. Am I right in saying that so long as it's
done between calls to performKsmps it should be ok? What say ye?

#include "csound.h"
#include  /* required for randomize() and random() */

int main(int argc, char **argv)
{
  // Create Csound.
  void *csound = csoundCreate(0);
  int ksmps = 64;
  int ran = 0;

  int result = csoundCompile(csound, argc, argv);
  if(!result) {
    while(csoundPerformKsmps(csound) == 0){
    ran = rand()%4 + 1;
    csoundSetKsmps(csound, ksmps+ran);
    printf("current ksmps size = %d", csoundGetKsmps(csound));
    }
    csoundCleanup(csound);
  }
  // Destroy Csound.
  csoundDestroy(csound);
  return result;
}

------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

God no! That would involve a clear understanding of how Csound
actually works. I simply did this:

PUBLIC uint32_t csoundSetKsmps(CSOUND *csound, int ksmps)
{
    csound->ksmps = ksmps;
}




On 5 February 2014 18:56,   wrote:
> I assume you set all the constants that depend on ksmps?
>
>
> Quoting Rory Walsh :
>
>> What consequences would changing the size of ksmps between calls to
>> csoundPerformKsmps have on things? I just tried a simple test there
>> and didn't notice any problems. I added a csoundSetKsmps() method to
>> the API and ran the example below with both real-time input/output and
>> straight synthesis examples. Am I right in saying that so long as it's
>> done between calls to performKsmps it should be ok? What say ye?
>>
>> #include "csound.h"
>> #include  /* required for randomize() and random() */
>>
>> int main(int argc, char **argv)
>> {
>>   // Create Csound.
>>   void *csound = csoundCreate(0);
>>   int ksmps = 64;
>>   int ran = 0;
>>
>>   int result = csoundCompile(csound, argc, argv);
>>   if(!result) {
>>     while(csoundPerformKsmps(csound) == 0){
>>     ran = rand()%4 + 1;
>>     csoundSetKsmps(csound, ksmps+ran);
>>     printf("current ksmps size = %d", csoundGetKsmps(csound));
>>     }
>>     csoundCleanup(csound);
>>   }
>>   // Destroy Csound.
>>   csoundDestroy(csound);
>>   return result;
>> }
>>
>> ------------------------------------------------------------------------------
>> Managing the Performance of Cloud-Based Applications
>> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>> Read the Whitepaper.
>> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
>
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I wouldn't want to do this. The engine needs to be stopped, all memory cleared and then everything started again.
Something like that would require a major redesign.

Victor
On 5 Feb 2014, at 19:02, Rory Walsh wrote:

> God no! That would involve a clear understanding of how Csound
> actually works. I simply did this:
> 
> PUBLIC uint32_t csoundSetKsmps(CSOUND *csound, int ksmps)
> {
>    csound->ksmps = ksmps;
> }
> 
> 
> 
> 
> On 5 February 2014 18:56,   wrote:
>> I assume you set all the constants that depend on ksmps?
>> 
>> 
>> Quoting Rory Walsh :
>> 
>>> What consequences would changing the size of ksmps between calls to
>>> csoundPerformKsmps have on things? I just tried a simple test there
>>> and didn't notice any problems. I added a csoundSetKsmps() method to
>>> the API and ran the example below with both real-time input/output and
>>> straight synthesis examples. Am I right in saying that so long as it's
>>> done between calls to performKsmps it should be ok? What say ye?
>>> 
>>> #include "csound.h"
>>> #include  /* required for randomize() and random() */
>>> 
>>> int main(int argc, char **argv)
>>> {
>>>  // Create Csound.
>>>  void *csound = csoundCreate(0);
>>>  int ksmps = 64;
>>>  int ran = 0;
>>> 
>>>  int result = csoundCompile(csound, argc, argv);
>>>  if(!result) {
>>>    while(csoundPerformKsmps(csound) == 0){
>>>    ran = rand()%4 + 1;
>>>    csoundSetKsmps(csound, ksmps+ran);
>>>    printf("current ksmps size = %d", csoundGetKsmps(csound));
>>>    }
>>>    csoundCleanup(csound);
>>>  }
>>>  // Destroy Csound.
>>>  csoundDestroy(csound);
>>>  return result;
>>> }
>>> 
>>> ------------------------------------------------------------------------------
>>> Managing the Performance of Cloud-Based Applications
>>> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>>> Read the Whitepaper.
>>> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> 
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> Managing the Performance of Cloud-Based Applications
>> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>> Read the Whitepaper.
>> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie




------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

At leat you need to set
     csound->onedksmps = FL(1.0) / (MYFLT) csound->ksmps;
and of course change in ksmps implies change in kr as sr = ksmps*kr
so you need to reset
     csound->kicvt = FMAXLEN / csound->ekr;
     csound->onedkr = FL(1.0) / csound->ekr;

and probably
     if (csound->ksmps != DFLT_KSMPS) {
       reallocateVarPoolMemory(csound, engineState->varPool);
     }

and of course re-init every active instrument that has any opcode that has 
local memory based on ksmps.

As Victor said, I would be very dubious that it can be done without danger 
or a total redesign.

==John ff



------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

The memory for all instruments instances depends on ksmps, if it has audio variables. In my opinion such a change will require 
a substantial redesign, if it is not to be a hack that will be hard to maintain and build on.

Victor

On 5 Feb 2014, at 19:38, Michael Gogins wrote:

> So the take-away is, a new API call that sets the constants would be fine -- as long as there are no opcodes that have local memory based on ksmps.
> 
> Couldn't we do some aspect-oriented programming, and inject a test and possible reallocation in those cases?
> 
> Regards,
> Mike
> 
> 
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
> 
> 
> On Wed, Feb 5, 2014 at 2:29 PM, jpff  wrote:
> At leat you need to set
>      csound->onedksmps = FL(1.0) / (MYFLT) csound->ksmps;
> and of course change in ksmps implies change in kr as sr = ksmps*kr
> so you need to reset
>      csound->kicvt = FMAXLEN / csound->ekr;
>      csound->onedkr = FL(1.0) / csound->ekr;
> 
> and probably
>      if (csound->ksmps != DFLT_KSMPS) {
>        reallocateVarPoolMemory(csound, engineState->varPool);
>      }
> 
> and of course re-init every active instrument that has any opcode that has
> local memory based on ksmps.
> 
> As Victor said, I would be very dubious that it can be done without danger
> or a total redesign.
> 
> ==John ff
> 
> 
> 
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk_______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie




------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

In Csound 6 there is a realtime mode which runs all init-time code in a separate thread, and also forces
diskin etc to use a separate thread for file reading, so no blocking operations are made in kperf.

Victor

On 5 Feb 2014, at 20:32, Michael Gogins wrote:

> Okay, I understand what you are saying, and I am sure you are correct.
> 
> I don't think I would want to do a redesign just for this issue, but what if we want to do one anyway for other issues?
> 
> At this point in time, how safe is Csound's performance loop (which is what plugins will call) for real time? Do we write to files, dynamically allocate memory, use mutexes instead of lock free constructs, inside csoundPerformKsmps?
> 
> Thanks for your thoughts,
> Mike
> 
> 
> 
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
> 
> 
> On Wed, Feb 5, 2014 at 3:08 PM, Victor Lazzarini  wrote:
> The memory for all instruments instances depends on ksmps, if it has audio variables. In my opinion such a change will require
> a substantial redesign, if it is not to be a hack that will be hard to maintain and build on.
> 
> Victor
> 
> On 5 Feb 2014, at 19:38, Michael Gogins wrote:
> 
> > So the take-away is, a new API call that sets the constants would be fine -- as long as there are no opcodes that have local memory based on ksmps.
> >
> > Couldn't we do some aspect-oriented programming, and inject a test and possible reallocation in those cases?
> >
> > Regards,
> > Mike
> >
> >
> > -----------------------------------------------------
> > Michael Gogins
> > Irreducible Productions
> > http://michaelgogins.tumblr.com
> > Michael dot Gogins at gmail dot com
> >
> >
> > On Wed, Feb 5, 2014 at 2:29 PM, jpff  wrote:
> > At leat you need to set
> >      csound->onedksmps = FL(1.0) / (MYFLT) csound->ksmps;
> > and of course change in ksmps implies change in kr as sr = ksmps*kr
> > so you need to reset
> >      csound->kicvt = FMAXLEN / csound->ekr;
> >      csound->onedkr = FL(1.0) / csound->ekr;
> >
> > and probably
> >      if (csound->ksmps != DFLT_KSMPS) {
> >        reallocateVarPoolMemory(csound, engineState->varPool);
> >      }
> >
> > and of course re-init every active instrument that has any opcode that has
> > local memory based on ksmps.
> >
> > As Victor said, I would be very dubious that it can be done without danger
> > or a total redesign.
> >
> > ==John ff
> >
> >
> >
> > ------------------------------------------------------------------------------
> > Managing the Performance of Cloud-Based Applications
> > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> > Read the Whitepaper.
> > http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Csound-devel mailing list
> > Csound-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/csound-devel
> >
> > ------------------------------------------------------------------------------
> > Managing the Performance of Cloud-Based Applications
> > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> > Read the Whitepaper.
> > http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk_______________________________________________
> > Csound-devel mailing list
> > Csound-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> Dr Victor Lazzarini
> Senior Lecturer
> Dept. of Music
> NUI Maynooth Ireland
> tel.: +353 1 708 3545
> Victor dot Lazzarini AT nuim dot ie
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk_______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie




------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

The realtime mode is as complete as it can be. It does not protect against an opcode that is written
with blocking operations in the k-pass, which it can't predict. However, as far as I can see that is a rare
thing, and the key transgressors have been dealt with by new asynchronous code. 

In performKsmps() and performBuffer() there is one lock that is used to protect against 
certain API calls (e.g. compileOrc()), to ensure thread safety.

Victor
On 5 Feb 2014, at 21:06, Michael Gogins wrote:

> Yes, I knew about the realtime mode, and was wondering how complete it is.
> 
> Mutexes are still non-real-time operations, are there mutexes in kperf?
> 
> Regards,
> Mike
> 
> 
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
> 
> 
> On Wed, Feb 5, 2014 at 3:47 PM, Victor Lazzarini  wrote:
> In Csound 6 there is a realtime mode which runs all init-time code in a separate thread, and also forces
> diskin etc to use a separate thread for file reading, so no blocking operations are made in kperf.
> 
> Victor
> 
> On 5 Feb 2014, at 20:32, Michael Gogins wrote:
> 
> > Okay, I understand what you are saying, and I am sure you are correct.
> >
> > I don't think I would want to do a redesign just for this issue, but what if we want to do one anyway for other issues?
> >
> > At this point in time, how safe is Csound's performance loop (which is what plugins will call) for real time? Do we write to files, dynamically allocate memory, use mutexes instead of lock free constructs, inside csoundPerformKsmps?
> >
> > Thanks for your thoughts,
> > Mike
> >
> >
> >
> > -----------------------------------------------------
> > Michael Gogins
> > Irreducible Productions
> > http://michaelgogins.tumblr.com
> > Michael dot Gogins at gmail dot com
> >
> >
> > On Wed, Feb 5, 2014 at 3:08 PM, Victor Lazzarini  wrote:
> > The memory for all instruments instances depends on ksmps, if it has audio variables. In my opinion such a change will require
> > a substantial redesign, if it is not to be a hack that will be hard to maintain and build on.
> >
> > Victor
> >
> > On 5 Feb 2014, at 19:38, Michael Gogins wrote:
> >
> > > So the take-away is, a new API call that sets the constants would be fine -- as long as there are no opcodes that have local memory based on ksmps.
> > >
> > > Couldn't we do some aspect-oriented programming, and inject a test and possible reallocation in those cases?
> > >
> > > Regards,
> > > Mike
> > >
> > >
> > > -----------------------------------------------------
> > > Michael Gogins
> > > Irreducible Productions
> > > http://michaelgogins.tumblr.com
> > > Michael dot Gogins at gmail dot com
> > >
> > >
> > > On Wed, Feb 5, 2014 at 2:29 PM, jpff  wrote:
> > > At leat you need to set
> > >      csound->onedksmps = FL(1.0) / (MYFLT) csound->ksmps;
> > > and of course change in ksmps implies change in kr as sr = ksmps*kr
> > > so you need to reset
> > >      csound->kicvt = FMAXLEN / csound->ekr;
> > >      csound->onedkr = FL(1.0) / csound->ekr;
> > >
> > > and probably
> > >      if (csound->ksmps != DFLT_KSMPS) {
> > >        reallocateVarPoolMemory(csound, engineState->varPool);
> > >      }
> > >
> > > and of course re-init every active instrument that has any opcode that has
> > > local memory based on ksmps.
> > >
> > > As Victor said, I would be very dubious that it can be done without danger
> > > or a total redesign.
> > >
> > > ==John ff
> > >
> > >
> > >
> > > ------------------------------------------------------------------------------
> > > Managing the Performance of Cloud-Based Applications
> > > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> > > Read the Whitepaper.
> > > http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
> > > _______________________________________________
> > > Csound-devel mailing list
> > > Csound-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/csound-devel
> > >
> > > ------------------------------------------------------------------------------
> > > Managing the Performance of Cloud-Based Applications
> > > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> > > Read the Whitepaper.
> > > http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk_______________________________________________
> > > Csound-devel mailing list
> > > Csound-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/csound-devel
> >
> > Dr Victor Lazzarini
> > Senior Lecturer
> > Dept. of Music
> > NUI Maynooth Ireland
> > tel.: +353 1 708 3545
> > Victor dot Lazzarini AT nuim dot ie
> >
> >
> >
> >
> > ------------------------------------------------------------------------------
> > Managing the Performance of Cloud-Based Applications
> > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> > Read the Whitepaper.
> > http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Csound-devel mailing list
> > Csound-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/csound-devel
> >
> > ------------------------------------------------------------------------------
> > Managing the Performance of Cloud-Based Applications
> > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> > Read the Whitepaper.
> > http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk_______________________________________________
> > Csound-devel mailing list
> > Csound-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> Dr Victor Lazzarini
> Senior Lecturer
> Dept. of Music
> NUI Maynooth Ireland
> tel.: +353 1 708 3545
> Victor dot Lazzarini AT nuim dot ie
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk_______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie




------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

yes, they are safe. AuxAlloc() is the recommended one.
On 5 Feb 2014, at 21:29, Michael Gogins wrote:

> That's very good.
> 
> I do dynamic memory allocation and thread synchronization in my own opcode plugins. The allocation is about dynamic collections. The synchronization is all about being thread-safe for multi-threaded rendering. I could look at this.
> 
> Do I understand that when an opcode uses Csound's allocators, that is safe? I could make my code use those allocators as well in that case.
> 
> Regards,
> Mike
> 
> 
> 
> 
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
> 
> 
> On Wed, Feb 5, 2014 at 4:19 PM, Victor Lazzarini  wrote:
> The realtime mode is as complete as it can be. It does not protect against an opcode that is written
> with blocking operations in the k-pass, which it can't predict. However, as far as I can see that is a rare
> thing, and the key transgressors have been dealt with by new asynchronous code.
> 
> In performKsmps() and performBuffer() there is one lock that is used to protect against
> certain API calls (e.g. compileOrc()), to ensure thread safety.
> 
> Victor
> On 5 Feb 2014, at 21:06, Michael Gogins wrote:
> 
> > Yes, I knew about the realtime mode, and was wondering how complete it is.
> >
> > Mutexes are still non-real-time operations, are there mutexes in kperf?
> >
> > Regards,
> > Mike
> >
> >
> > -----------------------------------------------------
> > Michael Gogins
> > Irreducible Productions
> > http://michaelgogins.tumblr.com
> > Michael dot Gogins at gmail dot com
> >
> >
> > On Wed, Feb 5, 2014 at 3:47 PM, Victor Lazzarini  wrote:
> > In Csound 6 there is a realtime mode which runs all init-time code in a separate thread, and also forces
> > diskin etc to use a separate thread for file reading, so no blocking operations are made in kperf.
> >
> > Victor
> >
> > On 5 Feb 2014, at 20:32, Michael Gogins wrote:
> >
> > > Okay, I understand what you are saying, and I am sure you are correct.
> > >
> > > I don't think I would want to do a redesign just for this issue, but what if we want to do one anyway for other issues?
> > >
> > > At this point in time, how safe is Csound's performance loop (which is what plugins will call) for real time? Do we write to files, dynamically allocate memory, use mutexes instead of lock free constructs, inside csoundPerformKsmps?
> > >
> > > Thanks for your thoughts,
> > > Mike
> > >
> > >
> > >
> > > -----------------------------------------------------
> > > Michael Gogins
> > > Irreducible Productions
> > > http://michaelgogins.tumblr.com
> > > Michael dot Gogins at gmail dot com
> > >
> > >
> > > On Wed, Feb 5, 2014 at 3:08 PM, Victor Lazzarini  wrote:
> > > The memory for all instruments instances depends on ksmps, if it has audio variables. In my opinion such a change will require
> > > a substantial redesign, if it is not to be a hack that will be hard to maintain and build on.
> > >
> > > Victor
> > >
> > > On 5 Feb 2014, at 19:38, Michael Gogins wrote:
> > >
> > > > So the take-away is, a new API call that sets the constants would be fine -- as long as there are no opcodes that have local memory based on ksmps.
> > > >
> > > > Couldn't we do some aspect-oriented programming, and inject a test and possible reallocation in those cases?
> > > >
> > > > Regards,
> > > > Mike
> > > >
> > > >
> > > > -----------------------------------------------------
> > > > Michael Gogins
> > > > Irreducible Productions
> > > > http://michaelgogins.tumblr.com
> > > > Michael dot Gogins at gmail dot com
> > > >
> > > >
> > > > On Wed, Feb 5, 2014 at 2:29 PM, jpff  wrote:
> > > > At leat you need to set
> > > >      csound->onedksmps = FL(1.0) / (MYFLT) csound->ksmps;
> > > > and of course change in ksmps implies change in kr as sr = ksmps*kr
> > > > so you need to reset
> > > >      csound->kicvt = FMAXLEN / csound->ekr;
> > > >      csound->onedkr = FL(1.0) / csound->ekr;
> > > >
> > > > and probably
> > > >      if (csound->ksmps != DFLT_KSMPS) {
> > > >        reallocateVarPoolMemory(csound, engineState->varPool);
> > > >      }
> > > >
> > > > and of course re-init every active instrument that has any opcode that has
> > > > local memory based on ksmps.
> > > >
> > > > As Victor said, I would be very dubious that it can be done without danger
> > > > or a total redesign.
> > > >
> > > > ==John ff
> > > >
> > > >
> > > >
> > > > ------------------------------------------------------------------------------
> > > > Managing the Performance of Cloud-Based Applications
> > > > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> > > > Read the Whitepaper.
> > > > http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
> > > > _______________________________________________
> > > > Csound-devel mailing list
> > > > Csound-devel@lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/csound-devel
> > > >
> > > > ------------------------------------------------------------------------------
> > > > Managing the Performance of Cloud-Based Applications
> > > > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> > > > Read the Whitepaper.
> > > > http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk_______________________________________________
> > > > Csound-devel mailing list
> > > > Csound-devel@lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/csound-devel
> > >
> > > Dr Victor Lazzarini
> > > Senior Lecturer
> > > Dept. of Music
> > > NUI Maynooth Ireland
> > > tel.: +353 1 708 3545
> > > Victor dot Lazzarini AT nuim dot ie
> > >
> > >
> > >
> > >
> > > ------------------------------------------------------------------------------
> > > Managing the Performance of Cloud-Based Applications
> > > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> > > Read the Whitepaper.
> > > http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
> > > _______________________________________________
> > > Csound-devel mailing list
> > > Csound-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/csound-devel
> > >
> > > ------------------------------------------------------------------------------
> > > Managing the Performance of Cloud-Based Applications
> > > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> > > Read the Whitepaper.
> > > http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk_______________________________________________
> > > Csound-devel mailing list
> > > Csound-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/csound-devel
> >
> > Dr Victor Lazzarini
> > Senior Lecturer
> > Dept. of Music
> > NUI Maynooth Ireland
> > tel.: +353 1 708 3545
> > Victor dot Lazzarini AT nuim dot ie
> >
> >
> >
> >
> > ------------------------------------------------------------------------------
> > Managing the Performance of Cloud-Based Applications
> > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> > Read the Whitepaper.
> > http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Csound-devel mailing list
> > Csound-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/csound-devel
> >
> > ------------------------------------------------------------------------------
> > Managing the Performance of Cloud-Based Applications
> > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> > Read the Whitepaper.
> > http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk_______________________________________________
> > Csound-devel mailing list
> > Csound-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> Dr Victor Lazzarini
> Senior Lecturer
> Dept. of Music
> NUI Maynooth Ireland
> tel.: +353 1 708 3545
> Victor dot Lazzarini AT nuim dot ie
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk_______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie




------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

This brings up an interesting issue.  We might consider replacing our
current mmalloc/mcalloc/mfree to use a real-time safe allocator. I
think Roger Dannenberg's Aura
(https://sourceforge.net/p/aurart/code/HEAD/tree/trunk/aura4/src/aura/auramem.cpp)
and SuperCollider use something similar of pre-allocating a large
chunk of memory and allocating from that.

We have code that uses mfree(),mcalloc(), and mfree().  It might be
nice to replace all calls to those functions with csound->Malloc,
csound->Calloc, and csound->Free.  That would allow us to swap in
different memory allocators.



On Wed, Feb 5, 2014 at 4:29 PM, Michael Gogins  wrote:
> That's very good.
>
> I do dynamic memory allocation and thread synchronization in my own opcode
> plugins. The allocation is about dynamic collections. The synchronization is
> all about being thread-safe for multi-threaded rendering. I could look at
> this.
>
> Do I understand that when an opcode uses Csound's allocators, that is safe?
> I could make my code use those allocators as well in that case.
>
> Regards,
> Mike
>
>
>
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Wed, Feb 5, 2014 at 4:19 PM, Victor Lazzarini 
> wrote:
>>
>> The realtime mode is as complete as it can be. It does not protect against
>> an opcode that is written
>> with blocking operations in the k-pass, which it can't predict. However,
>> as far as I can see that is a rare
>> thing, and the key transgressors have been dealt with by new asynchronous
>> code.
>>
>> In performKsmps() and performBuffer() there is one lock that is used to
>> protect against
>> certain API calls (e.g. compileOrc()), to ensure thread safety.
>>
>> Victor
>> On 5 Feb 2014, at 21:06, Michael Gogins wrote:
>>
>> > Yes, I knew about the realtime mode, and was wondering how complete it
>> > is.
>> >
>> > Mutexes are still non-real-time operations, are there mutexes in kperf?
>> >
>> > Regards,
>> > Mike
>> >
>> >
>> > -----------------------------------------------------
>> > Michael Gogins
>> > Irreducible Productions
>> > http://michaelgogins.tumblr.com
>> > Michael dot Gogins at gmail dot com
>> >
>> >
>> > On Wed, Feb 5, 2014 at 3:47 PM, Victor Lazzarini
>> >  wrote:
>> > In Csound 6 there is a realtime mode which runs all init-time code in a
>> > separate thread, and also forces
>> > diskin etc to use a separate thread for file reading, so no blocking
>> > operations are made in kperf.
>> >
>> > Victor
>> >
>> > On 5 Feb 2014, at 20:32, Michael Gogins wrote:
>> >
>> > > Okay, I understand what you are saying, and I am sure you are correct.
>> > >
>> > > I don't think I would want to do a redesign just for this issue, but
>> > > what if we want to do one anyway for other issues?
>> > >
>> > > At this point in time, how safe is Csound's performance loop (which is
>> > > what plugins will call) for real time? Do we write to files, dynamically
>> > > allocate memory, use mutexes instead of lock free constructs, inside
>> > > csoundPerformKsmps?
>> > >
>> > > Thanks for your thoughts,
>> > > Mike
>> > >
>> > >
>> > >
>> > > -----------------------------------------------------
>> > > Michael Gogins
>> > > Irreducible Productions
>> > > http://michaelgogins.tumblr.com
>> > > Michael dot Gogins at gmail dot com
>> > >
>> > >
>> > > On Wed, Feb 5, 2014 at 3:08 PM, Victor Lazzarini
>> > >  wrote:
>> > > The memory for all instruments instances depends on ksmps, if it has
>> > > audio variables. In my opinion such a change will require
>> > > a substantial redesign, if it is not to be a hack that will be hard to
>> > > maintain and build on.
>> > >
>> > > Victor
>> > >
>> > > On 5 Feb 2014, at 19:38, Michael Gogins wrote:
>> > >
>> > > > So the take-away is, a new API call that sets the constants would be
>> > > > fine -- as long as there are no opcodes that have local memory based on
>> > > > ksmps.
>> > > >
>> > > > Couldn't we do some aspect-oriented programming, and inject a test
>> > > > and possible reallocation in those cases?
>> > > >
>> > > > Regards,
>> > > > Mike
>> > > >
>> > > >
>> > > > -----------------------------------------------------
>> > > > Michael Gogins
>> > > > Irreducible Productions
>> > > > http://michaelgogins.tumblr.com
>> > > > Michael dot Gogins at gmail dot com
>> > > >
>> > > >
>> > > > On Wed, Feb 5, 2014 at 2:29 PM, jpff  wrote:
>> > > > At leat you need to set
>> > > >      csound->onedksmps = FL(1.0) / (MYFLT) csound->ksmps;
>> > > > and of course change in ksmps implies change in kr as sr = ksmps*kr
>> > > > so you need to reset
>> > > >      csound->kicvt = FMAXLEN / csound->ekr;
>> > > >      csound->onedkr = FL(1.0) / csound->ekr;
>> > > >
>> > > > and probably
>> > > >      if (csound->ksmps != DFLT_KSMPS) {
>> > > >        reallocateVarPoolMemory(csound, engineState->varPool);
>> > > >      }
>> > > >
>> > > > and of course re-init every active instrument that has any opcode
>> > > > that has
>> > > > local memory based on ksmps.
>> > > >
>> > > > As Victor said, I would be very dubious that it can be done without
>> > > > danger
>> > > > or a total redesign.
>> > > >
>> > > > ==John ff
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > ------------------------------------------------------------------------------
>> > > > Managing the Performance of Cloud-Based Applications
>> > > > Take advantage of what the Cloud has to offer - Avoid Common
>> > > > Pitfalls.
>> > > > Read the Whitepaper.
>> > > >
>> > > > http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
>> > > > _______________________________________________
>> > > > Csound-devel mailing list
>> > > > Csound-devel@lists.sourceforge.net
>> > > > https://lists.sourceforge.net/lists/listinfo/csound-devel
>> > > >
>> > > >
>> > > > ------------------------------------------------------------------------------
>> > > > Managing the Performance of Cloud-Based Applications
>> > > > Take advantage of what the Cloud has to offer - Avoid Common
>> > > > Pitfalls.
>> > > > Read the Whitepaper.
>> > > >
>> > > > http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk_______________________________________________
>> > > > Csound-devel mailing list
>> > > > Csound-devel@lists.sourceforge.net
>> > > > https://lists.sourceforge.net/lists/listinfo/csound-devel
>> > >
>> > > Dr Victor Lazzarini
>> > > Senior Lecturer
>> > > Dept. of Music
>> > > NUI Maynooth Ireland
>> > > tel.: +353 1 708 3545
>> > > Victor dot Lazzarini AT nuim dot ie
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > ------------------------------------------------------------------------------
>> > > Managing the Performance of Cloud-Based Applications
>> > > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>> > > Read the Whitepaper.
>> > >
>> > > http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
>> > > _______________________________________________
>> > > Csound-devel mailing list
>> > > Csound-devel@lists.sourceforge.net
>> > > https://lists.sourceforge.net/lists/listinfo/csound-devel
>> > >
>> > >
>> > > ------------------------------------------------------------------------------
>> > > Managing the Performance of Cloud-Based Applications
>> > > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>> > > Read the Whitepaper.
>> > >
>> > > http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk_______________________________________________
>> > > Csound-devel mailing list
>> > > Csound-devel@lists.sourceforge.net
>> > > https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >
>> > Dr Victor Lazzarini
>> > Senior Lecturer
>> > Dept. of Music
>> > NUI Maynooth Ireland
>> > tel.: +353 1 708 3545
>> > Victor dot Lazzarini AT nuim dot ie
>> >
>> >
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Managing the Performance of Cloud-Based Applications
>> > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>> > Read the Whitepaper.
>> >
>> > http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
>> > _______________________________________________
>> > Csound-devel mailing list
>> > Csound-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Managing the Performance of Cloud-Based Applications
>> > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>> > Read the Whitepaper.
>> >
>> > http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk_______________________________________________
>> > Csound-devel mailing list
>> > Csound-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> Dr Victor Lazzarini
>> Senior Lecturer
>> Dept. of Music
>> NUI Maynooth Ireland
>> tel.: +353 1 708 3545
>> Victor dot Lazzarini AT nuim dot ie
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Managing the Performance of Cloud-Based Applications
>> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>> Read the Whitepaper.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I am not sure I understand you: mcalloc() => csound->Calloc() etc. What do you mean by replacing these?

> We have code that uses mfree(),mcalloc(), and mfree().  It might be
> nice to replace all calls to those functions with csound->Malloc,
> csound->Calloc, and csound->Free.  That would allow us to swap in
> different memory allocators.
> 


------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

For us to have a replacable memory allocator, we'd need to change code
that uses mfree() to use csound->Free().  For example, in
csound_orc_compile.c, we have things like:

Engine/csound_orc_compile.c:209:

char** args = mmalloc(csound, sizeof(char*) * (argCount + 1));

which we'd need to change to:

char** args = csound->Malloc(csound, sizeof(char*) * (argCount + 1));

We have code using the function instead of the pointer in a number of
places.  Swapping that out would give us the versatility to introduce
different allocators.

On Wed, Feb 5, 2014 at 4:50 PM, Victor Lazzarini
 wrote:
> I am not sure I understand you: mcalloc() => csound->Calloc() etc. What do you mean by replacing these?
>
>> We have code that uses mfree(),mcalloc(), and mfree().  It might be
>> nice to replace all calls to those functions with csound->Malloc,
>> csound->Calloc, and csound->Free.  That would allow us to swap in
>> different memory allocators.
>>
>
>
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Then we don't need to do anything because, csound->Free(), csound->Malloc(), csound->Calloc() are
the same as mfree(), mmalloc() and mcalloc(). Just take a look at csound.c:249-251.

Victor
On 6 Feb 2014, at 00:51, Steven Yi wrote:

> For us to have a replacable memory allocator, we'd need to change code
> that uses mfree() to use csound->Free().  For example, in
> csound_orc_compile.c, we have things like:
> 
> Engine/csound_orc_compile.c:209:
> 
> char** args = mmalloc(csound, sizeof(char*) * (argCount + 1));
> 
> which we'd need to change to:
> 
> char** args = csound->Malloc(csound, sizeof(char*) * (argCount + 1));
> 
> We have code using the function instead of the pointer in a number of
> places.  Swapping that out would give us the versatility to introduce
> different allocators.
> 
> On Wed, Feb 5, 2014 at 4:50 PM, Victor Lazzarini
>  wrote:
>> I am not sure I understand you: mcalloc() => csound->Calloc() etc. What do you mean by replacing these?
>> 
>>> We have code that uses mfree(),mcalloc(), and mfree().  It might be
>>> nice to replace all calls to those functions with csound->Malloc,
>>> csound->Calloc, and csound->Free.  That would allow us to swap in
>>> different memory allocators.
>>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> Managing the Performance of Cloud-Based Applications
>> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>> Read the Whitepaper.
>> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie




------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

But this doesn't serve the purpose of replaceable allocators unless we
dereference what is set on CSOUND, rather than calling a function
directly.  I think it'll make more sense if I elaborate on use case.
For example, let's say we want to use two different allocators, one
for if --realtime is set that uses a realtime-friendly allocator, and
the current one if we're rendering to disk.  The former might have
settings like default memblock size for how large the initial pool
should be, so that user's can fine-tune the performance
characteristics (i.e. if on mobile device, use smaller size, if on
desktop, use a larger size).  For the disk render one, there's no
worries about realtime so just allocate away.

There is precedent for this in C++'s STL library.  Some description is
available at [1]. Boost has a pool allocator that can be used with
STL[2].

BTW: I think I was incorrect about SuperCollider and Aura's
allocators. I think SuperCollider has a large set of memory on the
stack, while Aura allocates one large block on the heap at start.  We
could experiment pretty easily with having different allocator
strategies if everything that allocated memory used csound->Func()
instead of func() directly.  (For example, It might be nice to have a
hybrid allocator that starts on the stack and expands out to the heap
if necessary.)

Hope that makes sense on what I'm thinking! Let me know if there's
still something I haven't made clear.

Thanks!
steven


[1] - http://en.wikipedia.org/wiki/Allocator_(C%2B%2B)
[2] - http://www.boost.org/doc/libs/1_55_0/libs/pool/doc/html/boost_pool/pool/interfaces.html



On Thu, Feb 6, 2014 at 2:13 AM, Victor Lazzarini
 wrote:
> Then we don't need to do anything because, csound->Free(), csound->Malloc(), csound->Calloc() are
> the same as mfree(), mmalloc() and mcalloc(). Just take a look at csound.c:249-251.
>
> Victor
> On 6 Feb 2014, at 00:51, Steven Yi wrote:
>
>> For us to have a replacable memory allocator, we'd need to change code
>> that uses mfree() to use csound->Free().  For example, in
>> csound_orc_compile.c, we have things like:
>>
>> Engine/csound_orc_compile.c:209:
>>
>> char** args = mmalloc(csound, sizeof(char*) * (argCount + 1));
>>
>> which we'd need to change to:
>>
>> char** args = csound->Malloc(csound, sizeof(char*) * (argCount + 1));
>>
>> We have code using the function instead of the pointer in a number of
>> places.  Swapping that out would give us the versatility to introduce
>> different allocators.
>>
>> On Wed, Feb 5, 2014 at 4:50 PM, Victor Lazzarini
>>  wrote:
>>> I am not sure I understand you: mcalloc() => csound->Calloc() etc. What do you mean by replacing these?
>>>
>>>> We have code that uses mfree(),mcalloc(), and mfree().  It might be
>>>> nice to replace all calls to those functions with csound->Malloc,
>>>> csound->Calloc, and csound->Free.  That would allow us to swap in
>>>> different memory allocators.
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Managing the Performance of Cloud-Based Applications
>>> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>>> Read the Whitepaper.
>>> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> Managing the Performance of Cloud-Based Applications
>> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>> Read the Whitepaper.
>> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> Dr Victor Lazzarini
> Senior Lecturer
> Dept. of Music
> NUI Maynooth Ireland
> tel.: +353 1 708 3545
> Victor dot Lazzarini AT nuim dot ie
>
>
>
>
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I was only pointing out that they are currently the same thing.

On 6 Feb 2014, at 14:09, Steven Yi  wrote:

> But this doesn't serve the purpose of replaceable allocators unless we
> dereference what is set on CSOUND, rather than calling a function
> directly.  I think it'll make more sense if I elaborate on use case.
> For example, let's say we want to use two different allocators, one
> for if --realtime is set that uses a realtime-friendly allocator, and
> the current one if we're rendering to disk.  The former might have
> settings like default memblock size for how large the initial pool
> should be, so that user's can fine-tune the performance
> characteristics (i.e. if on mobile device, use smaller size, if on
> desktop, use a larger size).  For the disk render one, there's no
> worries about realtime so just allocate away.
> 
> There is precedent for this in C++'s STL library.  Some description is
> available at [1]. Boost has a pool allocator that can be used with
> STL[2].
> 
> BTW: I think I was incorrect about SuperCollider and Aura's
> allocators. I think SuperCollider has a large set of memory on the
> stack, while Aura allocates one large block on the heap at start.  We
> could experiment pretty easily with having different allocator
> strategies if everything that allocated memory used csound->Func()
> instead of func() directly.  (For example, It might be nice to have a
> hybrid allocator that starts on the stack and expands out to the heap
> if necessary.)
> 
> Hope that makes sense on what I'm thinking! Let me know if there's
> still something I haven't made clear.
> 
> Thanks!
> steven
> 
> 
> [1] - http://en.wikipedia.org/wiki/Allocator_(C%2B%2B)
> [2] - http://www.boost.org/doc/libs/1_55_0/libs/pool/doc/html/boost_pool/pool/interfaces.html
> 
> 
> 
> On Thu, Feb 6, 2014 at 2:13 AM, Victor Lazzarini
>  wrote:
>> Then we don't need to do anything because, csound->Free(), csound->Malloc(), csound->Calloc() are
>> the same as mfree(), mmalloc() and mcalloc(). Just take a look at csound.c:249-251.
>> 
>> Victor
>> On 6 Feb 2014, at 00:51, Steven Yi wrote:
>> 
>>> For us to have a replacable memory allocator, we'd need to change code
>>> that uses mfree() to use csound->Free().  For example, in
>>> csound_orc_compile.c, we have things like:
>>> 
>>> Engine/csound_orc_compile.c:209:
>>> 
>>> char** args = mmalloc(csound, sizeof(char*) * (argCount + 1));
>>> 
>>> which we'd need to change to:
>>> 
>>> char** args = csound->Malloc(csound, sizeof(char*) * (argCount + 1));
>>> 
>>> We have code using the function instead of the pointer in a number of
>>> places.  Swapping that out would give us the versatility to introduce
>>> different allocators.
>>> 
>>> On Wed, Feb 5, 2014 at 4:50 PM, Victor Lazzarini
>>>  wrote:
>>>> I am not sure I understand you: mcalloc() => csound->Calloc() etc. What do you mean by replacing these?
>>>> 
>>>>> We have code that uses mfree(),mcalloc(), and mfree().  It might be
>>>>> nice to replace all calls to those functions with csound->Malloc,
>>>>> csound->Calloc, and csound->Free.  That would allow us to swap in
>>>>> different memory allocators.
>>>>> 
>>>> 
>>>> 
>>>> ------------------------------------------------------------------------------
>>>> Managing the Performance of Cloud-Based Applications
>>>> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>>>> Read the Whitepaper.
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>> 
>>> ------------------------------------------------------------------------------
>>> Managing the Performance of Cloud-Based Applications
>>> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>>> Read the Whitepaper.
>>> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> 
>> Dr Victor Lazzarini
>> Senior Lecturer
>> Dept. of Music
>> NUI Maynooth Ireland
>> tel.: +353 1 708 3545
>> Victor dot Lazzarini AT nuim dot ie
>> 
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> Managing the Performance of Cloud-Based Applications
>> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>> Read the Whitepaper.
>> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Yes, they are the same at the moment.  I think we're on the same page
now. I've filed request 31:

https://sourceforge.net/p/csound/feature-requests/31/

to track this work.  (I'm unable to look at this at the moment, but
it's an easy change if anyone wants to tackle it.  Otherwise, I'll
look at it after the UDO TypeSystem changes.)

On Thu, Feb 6, 2014 at 10:10 AM, Victor Lazzarini
 wrote:
> I was only pointing out that they are currently the same thing.
>
> On 6 Feb 2014, at 14:09, Steven Yi  wrote:
>
>> But this doesn't serve the purpose of replaceable allocators unless we
>> dereference what is set on CSOUND, rather than calling a function
>> directly.  I think it'll make more sense if I elaborate on use case.
>> For example, let's say we want to use two different allocators, one
>> for if --realtime is set that uses a realtime-friendly allocator, and
>> the current one if we're rendering to disk.  The former might have
>> settings like default memblock size for how large the initial pool
>> should be, so that user's can fine-tune the performance
>> characteristics (i.e. if on mobile device, use smaller size, if on
>> desktop, use a larger size).  For the disk render one, there's no
>> worries about realtime so just allocate away.
>>
>> There is precedent for this in C++'s STL library.  Some description is
>> available at [1]. Boost has a pool allocator that can be used with
>> STL[2].
>>
>> BTW: I think I was incorrect about SuperCollider and Aura's
>> allocators. I think SuperCollider has a large set of memory on the
>> stack, while Aura allocates one large block on the heap at start.  We
>> could experiment pretty easily with having different allocator
>> strategies if everything that allocated memory used csound->Func()
>> instead of func() directly.  (For example, It might be nice to have a
>> hybrid allocator that starts on the stack and expands out to the heap
>> if necessary.)
>>
>> Hope that makes sense on what I'm thinking! Let me know if there's
>> still something I haven't made clear.
>>
>> Thanks!
>> steven
>>
>>
>> [1] - http://en.wikipedia.org/wiki/Allocator_(C%2B%2B)
>> [2] - http://www.boost.org/doc/libs/1_55_0/libs/pool/doc/html/boost_pool/pool/interfaces.html
>>
>>
>>
>> On Thu, Feb 6, 2014 at 2:13 AM, Victor Lazzarini
>>  wrote:
>>> Then we don't need to do anything because, csound->Free(), csound->Malloc(), csound->Calloc() are
>>> the same as mfree(), mmalloc() and mcalloc(). Just take a look at csound.c:249-251.
>>>
>>> Victor
>>> On 6 Feb 2014, at 00:51, Steven Yi wrote:
>>>
>>>> For us to have a replacable memory allocator, we'd need to change code
>>>> that uses mfree() to use csound->Free().  For example, in
>>>> csound_orc_compile.c, we have things like:
>>>>
>>>> Engine/csound_orc_compile.c:209:
>>>>
>>>> char** args = mmalloc(csound, sizeof(char*) * (argCount + 1));
>>>>
>>>> which we'd need to change to:
>>>>
>>>> char** args = csound->Malloc(csound, sizeof(char*) * (argCount + 1));
>>>>
>>>> We have code using the function instead of the pointer in a number of
>>>> places.  Swapping that out would give us the versatility to introduce
>>>> different allocators.
>>>>
>>>> On Wed, Feb 5, 2014 at 4:50 PM, Victor Lazzarini
>>>>  wrote:
>>>>> I am not sure I understand you: mcalloc() => csound->Calloc() etc. What do you mean by replacing these?
>>>>>
>>>>>> We have code that uses mfree(),mcalloc(), and mfree().  It might be
>>>>>> nice to replace all calls to those functions with csound->Malloc,
>>>>>> csound->Calloc, and csound->Free.  That would allow us to swap in
>>>>>> different memory allocators.
>>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Managing the Performance of Cloud-Based Applications
>>>>> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>>>>> Read the Whitepaper.
>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Managing the Performance of Cloud-Based Applications
>>>> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>>>> Read the Whitepaper.
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>> Dr Victor Lazzarini
>>> Senior Lecturer
>>> Dept. of Music
>>> NUI Maynooth Ireland
>>> tel.: +353 1 708 3545
>>> Victor dot Lazzarini AT nuim dot ie
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Managing the Performance of Cloud-Based Applications
>>> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>>> Read the Whitepaper.
>>> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> Managing the Performance of Cloud-Based Applications
>> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>> Read the Whitepaper.
>> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net