-- ___________________________________________________ Oded Ben-Tal http://ccrma.stanford.edu/~oded oded@ccrma.stanford.edu ------------------------------ Message: 5 Date: Tue, 04 Mar 2008 19:10:29 +0000 From: "Martin Peach" martin.peach@sympatico.ca Subject: Re: [PD] parallel processing To: zmoelnig@iem.at, pd-list@iem.at, marius.schebella@gmail.com Message-ID: BAY113-F39D51299C8B2E4ADB58279ED100@phx.gbl Content-Type: text/plain; format=flowed >sched_setaffinity >pthread_setaffinity_np (NPTL-pthreads) > >and i just found a linux-journal article: >http://www.linuxjournal.com/article/6799 > OK, thanks. Here's one about the MS version: http://msdn2.microsoft.com/en-us/library/ms684251(VS.85).aspx It mentions the function SetThreadAffinityMask(). Martin ------------------------------ Message: 6 Date: Tue, 04 Mar 2008 19:18:29 +0000 From: "Martin Peach" martin.peach@sympatico.ca Subject: Re: [PD] parallel processing To: zmoelnig@iem.at, pd-list@iem.at, marius.schebella@gmail.com Message-ID: BAY113-F409554EA88E226A0A8E330ED100@phx.gbl Content-Type: text/plain; format=flowed But on the Mac, it's not so hopeful: "Mac OS X does not export interfaces that identify processors or control thread placement-explicit thread to processor binding is not supported. Instead, the kernel manages all thread placement. Applications expect that the scheduler will, under most circumstances, run its threads using a good processor placement with respect to cache affinity." (http://developer.apple.com/releasenotes/Performance/RN-AffinityAPI/) Martin ------------------------------ Message: 7 Date: Tue, 4 Mar 2008 14:21:33 -0500 From: Brandon Zeeb bsoisoi@mac.com Subject: Re: [PD] parallel processing To: marius schebella marius.schebella@gmail.com Cc: "pd-list@iem.at Pure Data" pd-list@iem.at, andreeprefontaine@gmail.com Message-ID: 1BAB0DA4-D202-433E-82D9-038FA76EEFA5@mac.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes More specifically, my question is: How does PD's performance scale when the number of available
processing units increases from 2 to 4 and to 8 cores? Is the main
engine written in such a way as to take advantage of this, or is it
primarily a single-threaded? Possible scenarios could be: 1. I have a patch with 8 very intense sub patches. Do all of these
sub-patches run on the same core or are they spread out across
available processors? 2. Assume I have an 8 CPU system (dual quad opterons etc). I have 8
patches open within one Pd instance, do all 8 patches run on the same
core or 2, or do they spread out across all the available 8 cores? Besides running multiple copies of Pd, how does Pd scale on many-cpu
systems? Cheers, ~Brandon On Mar 4, 2008, at 11:53 AM, marius schebella wrote: > pd is only using one of 2, 4 or 8. is that what your question was? > marius. > > bsoisoi wrote: >> Along with the question posed by Marius, how does PD currently
>> scale on SMP systems with 2, 4, or 8 cores? >> Cheers, >> ~Brandon >> On Mar 4, 2008, at 11:39 AM, marius schebella wrote: >>> No, I missed LAC, but it is not surprising that people research in
>>> that >>> direction. I was looking through some papers yesterday, but not
>>> the one >>> from j?rgen, will catch up on that. >>> marius. >>> >>> Andr?e Pr?fontaine wrote: >>>> >>>> Le 08-03-04 ? 11:14, marius schebella a ?crit : >>>> >>>>> hi, >>>>> I am reading an old interview with james moorer (with curtis
>>>>> roads in >>>>> CMJ/6 1982). one funny thing is that he says, 'software
>>>>> synthesis is >>>>> either dead or dying[...] I am hoping it's demise will be quick
>>>>> and >>>>> relatively painless.' >>>>> in return he predicted all computation being done on special dsp
>>>>> chips. >>>>> in part he was right, but on the other hand the main cpu got
>>>>> more than >>>>> fast enough to survive (gfx is slightly different), but - and I am >>>>> coming to my point - he also was thinking about hundreds or
>>>>> thousands of >>>>> parallel processing elements. right now, we are going to have
>>>>> several >>>>> and in the future many many parallel CPUs, and the need for
>>>>> parallel >>>>> processing is back. miller was talking about that in montreal. >>>>> so I wonder how pd will survive that evolution? afaik the current >>>>> situation is poor in this regard. can anyone give an outview for
>>>>> the >>>>> future? would it be a jump from pd (I) 0.43 to pd II 0.1? >>>>> marius. >>>> >>>> Where you at Lac 2008? because J?rgen Reuter gave a lecture on
>>>> the topic >>>> with who you are interested. >>>> I do wonder too in this regard and where very interested in his >>>> presentation : exploiting multi-core architectures for fast modular >>>> synthesis >>>> >>>> Andr?e >>>>> _______________________________________________ >>>>> PD-list@iem.at mailing list >>>>> UNSUBSCRIBE and account-management -> >>>>> http://lists.puredata.info/listinfo/pd-list >>>> >>>> >>> >>> >>> _______________________________________________ >>> PD-list@iem.at mailing list >>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list > ------------------------------ Message: 8 Date: Tue, 04 Mar 2008 14:26:47 -0500 From: marius schebella marius.schebella@gmail.com Subject: Re: [PD] parallel processing To: Martin Peach martin.peach@sympatico.ca Cc: pd-list@iem.at, zmoelnig@iem.at Message-ID: 47CDA277.6010102@gmail.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed isn't the problem of pd right now, that the audio chain can't be chopped into different threads? if the pd audio chain would support threads for every object, would it be as easy as to add a (or some) line(s) of code for every dsp object? is it correct that some soundcards compute part of the audio chain on the soundchip? which parts? I only ask out of interest, I would not be able to implement any of the solutions :(, so feel free to ignore the questions, if you think this is more a developer discussion and to much theoretical right now... marius. Martin Peach wrote: >> sched_setaffinity >> pthread_setaffinity_np (NPTL-pthreads) >> >> and i just found a linux-journal article: >> http://www.linuxjournal.com/article/6799 >> > > OK, thanks. Here's one about the MS version: > http://msdn2.microsoft.com/en-us/library/ms684251(VS.85).aspx > > It mentions the function SetThreadAffinityMask(). > > > > Martin > > > ------------------------------ Message: 9 Date: Tue, 4 Mar 2008 11:34:06 -0800 From: Miller Puckette mpuckett@imusic1.ucsd.edu Subject: Re: [PD] Improved bug report: [expr] on Windows 2000 (XP non-professional) To: Patrice Colet pat@mamalala.org Cc: pd-list@iem.at, "David F. Place" d@vidplace.com Message-ID: 20080304193406.GA15084@imusic1.ucsd.edu Content-Type: text/plain; charset=us-ascii I haven't been able to figure out how to make windows-style makefiles call each other, so I have a batch file, 'build' that I call from the source directory, to call the other makefiles in other directories. (Of course, I haven't even tried again since 1999 or so to figure this out and it's probably easy now!) cheers Miller On Mon, Mar 03, 2008 at 12:39:32AM +0100, Patrice Colet wrote: > Okay, it's definitively a bug, the makefile.nt in pd-0.41-2 doesn't > build externals at all, so if it's not corrected, the bug will stay in > further versions. Also, I'm sure it's possible to use Makefile.in, for > all platforms. > > > David F. Place a ?crit : > > > > On Mar 2, 2008, at 5:03 PM, Patrice Colet wrote: > > > >> Hello, did you check if the expr.dll is present in extra folder? > > > > expr.dll is not present in the extra folder. In fact, there are no .dll > > files in the extra folder. > > > >> > > > > ___________________ > > (---o-------o-o-o---o-o-o----( > > David F. Place > > mailto:d@vidplace.com > > > > > > > > > _______________________________________________ > PD-list@iem.at mailing list > UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list ------------------------------ Message: 10 Date: Tue, 04 Mar 2008 19:38:44 +0000 From: Claude Heiland-Allen claudiusmaximus@goto10.org Subject: Re: [PD] parallel processing To: Brandon Zeeb bsoisoi@mac.com Cc: "pd-list@iem.at Pure Data" pd-list@iem.at, andreeprefontaine@gmail.com, marius schebella marius.schebella@gmail.com Message-ID: 47CDA544.7020508@goto10.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Brandon Zeeb wrote: > More specifically, my question is: > > How does PD's performance scale when the number of available
> processing units increases from 2 to 4 and to 8 cores? Is the main
> engine written in such a way as to take advantage of this, or is it
> primarily a single-threaded? Pd's engine is a single thread, it will use at most 100% of *one* core. Pd's gui is a single thread, it will use at most 100% of *one* core. The communication between engine <--> gui is suboptimal, which might limit things, but unlikely. > Besides running multiple copies of Pd, how does Pd scale on many-cpu
> systems? It doesn't. Claude -- http://claudiusmaximus.goto10.org ------------------------------ _______________________________________________ PD-list mailing list PD-list@iem.at to manage your subscription (including un-subscription) see http://lists.puredata.info/listinfo/pd-list End of PD-list Digest, Vol 36, Issue 16 *************************************** Royal Welsh College of Music & Drama Castle Grounds Cathays Park Cardiff CF10 3ER Royal Welsh College of Music & Drama Ltd A subsidiary of the University of Glamorgan Company registration 6013744, registered in England and Wales This e-mail is intended for the above named only, and may contain privileged or confidential information. If you are not the intended recipient, any disclosure, copying, distribution or reliance upon the e-mail is prohibited, and may be unlawful. If you are not the intended recipient, please contact postmaster@rwcmd.ac.uk, quoting your name and the name of the sender, then delete the e-mail from your system. Please note that neither RWCMD nor the sender accepts any liability for viruses and it is your responsibility to scan any attachments included with this e-mail. Coleg Brenhinol Cerdd a Drama Cymru Maes y Castell Parc Cathays Caerdydd CF10 3ER Coleg Brenhinol Cerdd a Drama Cymru Cyf Is-gwmni Prifysgol Morgannwg Cofrestriad cwmni 6013744, a gofrestrwyd yn Lloegr a Chymru Dim ond at ddefnydd yr unigolyn a enwir uchod y bwriedir yr e-bost hwn, a gall gynnwys gwybodaeth gyfrinachol. Os nad chi yw'r derbynnydd a fwriadwyd, gwaherddir i chi ledaenu, copio neu ddosbarthu'r e-bost, a gall hynny fod yn anghyfreithlon. Os nad chi yw'r derbynnydd a fwriadwyd, cysylltwch a postfeistr@cbcdc.ac.uk gan nodi eich enw ac enw'r anfonydd, ac yna dileu'r neges o'ch cyfrifiadur. Dylech nodi nad yw CBCDC na'r anfonydd yn derbyn unrhyw gyfrifoldeb am unrhyw firysau, ac eich cyfrifoldeb chi yw sganio unrhyw atodiadau sydd ynghlwm wrth yr e-bost hwn.