I am currently working on a synthetic example of many oscillators and
plucks

One note, 10s long

Threads   Elapse sec
1         0s340
2         0.334
3         0.263
4         0.281
5         0.297
6         0.286
7         0.288
8         0.330

So the thing is working.  I am suspecting that the overhead of a new
note or losing a note is too much.

Would appreciate other data points.

This is on 64bit Intel Core 7 running Linux, with a bug in the spinlock

==John ffitch

------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I haven't looked at the ParCS spinlock code, but with OpenMP you can
do a spinlock like this:

// waiting thread:
#pragma omp flush
while(flag==FALSE)
{
#pragma omp flush
}

// releasing thread:
flag = TRUE;
#pragma omp flush

The bug may possibly be due to the fact that the lock variable needs
to be valid across cache lines. The flushes in the OpenMP spinlock
ensure this validity.

Regards,
Mike

On Thu, Aug 5, 2010 at 12:05 PM, John ff  wrote:
> I am currently working on a synthetic example of many oscillators and
> plucks
>
> One note, 10s long
>
> Threads   Elapse sec
> 1         0s340
> 2         0.334
> 3         0.263
> 4         0.281
> 5         0.297
> 6         0.286
> 7         0.288
> 8         0.330
>
> So the thing is working.  I am suspecting that the overhead of a new
> note or losing a note is too much.
>
> Would appreciate other data points.
>
> This is on 64bit Intel Core 7 running Linux, with a bug in the spinlock
>
> ==John ffitch
>
> ------------------------------------------------------------------------------
> The Palm PDK Hot Apps Program offers developers who use the
> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
> of $1 Million in cash or HP Products. Visit us here for more details:
> http://p.sf.net/sfu/dev2dev-palm
> _______________________________________________
> 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

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

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

On 05/08/10 12:05, John ff wrote:
> I am currently working on a synthetic example of many oscillators and
> plucks
> 
> One note, 10s long
> 
> Threads   Elapse sec
> 1         0s340
> 2         0.334
> 3         0.263
> 4         0.281
> 5         0.297
> 6         0.286
> 7         0.288
> 8         0.330
> 
> So the thing is working.  I am suspecting that the overhead of a new
> note or losing a note is too much.
> 
> Would appreciate other data points.
> 
> This is on 64bit Intel Core 7 running Linux, with a bug in the spinlock

Last time I touched this issue (with Michael's parallel implementation
using gcc builtins, which caused a problem on sparc machines), I was
asked why does csound use its own implementation of spinlocks instead of
using libatomic-ops (now part of the Boehm-Demers-Weiser garbage
collector, but I'm pretty sure it can be extracted without problem,
license is bsd style) or pthread spinlocks (csound already uses pthread,
but OSX seems to not support pthread spinlocks yet).

-- 
Saludos,
Felipe Sateler

I agree that pthread_spin_lock and pthread_spin_unlock probably should
be used, at least for the time being.

But this needs to be wrapped such that spinlocks actually only are
used only if Csound is running more than 1 thread, and also there is
more than 1 core.

Regards,
Mike

On Fri, Aug 6, 2010 at 2:23 PM, Felipe Sateler  wrote:
> On 05/08/10 12:05, John ff wrote:
>> I am currently working on a synthetic example of many oscillators and
>> plucks
>>
>> One note, 10s long
>>
>> Threads   Elapse sec
>> 1         0s340
>> 2         0.334
>> 3         0.263
>> 4         0.281
>> 5         0.297
>> 6         0.286
>> 7         0.288
>> 8         0.330
>>
>> So the thing is working.  I am suspecting that the overhead of a new
>> note or losing a note is too much.
>>
>> Would appreciate other data points.
>>
>> This is on 64bit Intel Core 7 running Linux, with a bug in the spinlock
>
> Last time I touched this issue (with Michael's parallel implementation
> using gcc builtins, which caused a problem on sparc machines), I was
> asked why does csound use its own implementation of spinlocks instead of
> using libatomic-ops (now part of the Boehm-Demers-Weiser garbage
> collector, but I'm pretty sure it can be extracted without problem,
> license is bsd style) or pthread spinlocks (csound already uses pthread,
> but OSX seems to not support pthread spinlocks yet).
>
> --
> Saludos,
> Felipe Sateler
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>



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

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

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

If this is not usable on OSX, we could create API methods for things
like spinlock_create, spinlock_lock (spins here), etc.  On OSX we
could use OSSpinLock
(http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man3/OSSpinLockTry.3.html),
and elsewhere we could use pthread.

On Fri, Aug 6, 2010 at 2:33 PM, Michael Gogins  wrote:
> I agree that pthread_spin_lock and pthread_spin_unlock probably should
> be used, at least for the time being.
>
> But this needs to be wrapped such that spinlocks actually only are
> used only if Csound is running more than 1 thread, and also there is
> more than 1 core.
>
> Regards,
> Mike
>
> On Fri, Aug 6, 2010 at 2:23 PM, Felipe Sateler  wrote:
>> On 05/08/10 12:05, John ff wrote:
>>> I am currently working on a synthetic example of many oscillators and
>>> plucks
>>>
>>> One note, 10s long
>>>
>>> Threads   Elapse sec
>>> 1         0s340
>>> 2         0.334
>>> 3         0.263
>>> 4         0.281
>>> 5         0.297
>>> 6         0.286
>>> 7         0.288
>>> 8         0.330
>>>
>>> So the thing is working.  I am suspecting that the overhead of a new
>>> note or losing a note is too much.
>>>
>>> Would appreciate other data points.
>>>
>>> This is on 64bit Intel Core 7 running Linux, with a bug in the spinlock
>>
>> Last time I touched this issue (with Michael's parallel implementation
>> using gcc builtins, which caused a problem on sparc machines), I was
>> asked why does csound use its own implementation of spinlocks instead of
>> using libatomic-ops (now part of the Boehm-Demers-Weiser garbage
>> collector, but I'm pretty sure it can be extracted without problem,
>> license is bsd style) or pthread spinlocks (csound already uses pthread,
>> but OSX seems to not support pthread spinlocks yet).
>>
>> --
>> Saludos,
>> Felipe Sateler
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by
>>
>> Make an app they can't live without
>> Enter the BlackBerry Developer Challenge
>> http://p.sf.net/sfu/RIM-dev2dev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

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

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

Taking a step back, it is precisely because Csound is such an
obstinately "old school, C language, Unix command" style program that
we should be able to make it truly concurrent, more easily than other
software synthesizers.

Regards,
Mike

On Fri, Aug 6, 2010 at 2:35 PM, Steven Yi  wrote:
> If this is not usable on OSX, we could create API methods for things
> like spinlock_create, spinlock_lock (spins here), etc.  On OSX we
> could use OSSpinLock
> (http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man3/OSSpinLockTry.3.html),
> and elsewhere we could use pthread.
>
> On Fri, Aug 6, 2010 at 2:33 PM, Michael Gogins  wrote:
>> I agree that pthread_spin_lock and pthread_spin_unlock probably should
>> be used, at least for the time being.
>>
>> But this needs to be wrapped such that spinlocks actually only are
>> used only if Csound is running more than 1 thread, and also there is
>> more than 1 core.
>>
>> Regards,
>> Mike
>>
>> On Fri, Aug 6, 2010 at 2:23 PM, Felipe Sateler  wrote:
>>> On 05/08/10 12:05, John ff wrote:
>>>> I am currently working on a synthetic example of many oscillators and
>>>> plucks
>>>>
>>>> One note, 10s long
>>>>
>>>> Threads   Elapse sec
>>>> 1         0s340
>>>> 2         0.334
>>>> 3         0.263
>>>> 4         0.281
>>>> 5         0.297
>>>> 6         0.286
>>>> 7         0.288
>>>> 8         0.330
>>>>
>>>> So the thing is working.  I am suspecting that the overhead of a new
>>>> note or losing a note is too much.
>>>>
>>>> Would appreciate other data points.
>>>>
>>>> This is on 64bit Intel Core 7 running Linux, with a bug in the spinlock
>>>
>>> Last time I touched this issue (with Michael's parallel implementation
>>> using gcc builtins, which caused a problem on sparc machines), I was
>>> asked why does csound use its own implementation of spinlocks instead of
>>> using libatomic-ops (now part of the Boehm-Demers-Weiser garbage
>>> collector, but I'm pretty sure it can be extracted without problem,
>>> license is bsd style) or pthread spinlocks (csound already uses pthread,
>>> but OSX seems to not support pthread spinlocks yet).
>>>
>>> --
>>> Saludos,
>>> Felipe Sateler
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> This SF.net email is sponsored by
>>>
>>> Make an app they can't live without
>>> Enter the BlackBerry Developer Challenge
>>> http://p.sf.net/sfu/RIM-dev2dev
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>
>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by
>>
>> Make an app they can't live without
>> Enter the BlackBerry Developer Challenge
>> http://p.sf.net/sfu/RIM-dev2dev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



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

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

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