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
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 synthesisAndré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
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
marius schebella wrote:
pd is only using one of 2, 4 or 8. is that what your question was? marius.
well, it uses 2, as Pd is really 2 applications (pd-gui and pd-core); not big gains however, due to the bad separation between pd-gui and pd-core.
dfamdr IOhannes
IOhannes m zmoelnig wrote: marius schebella wrote:
pd is only using one of 2, 4 or 8. is that what your question was? marius.
well, it uses 2, as Pd is really 2 applications (pd-gui and pd-core); not big gains however, due to the bad separation between pd-gui and pd-core.
And if an external starts its own thread will it run on another core? Does any OS allow a programmer to control which processor the code runs on?
Martin
Martin Peach wrote:
IOhannes m zmoelnig wrote: marius schebella wrote:
pd is only using one of 2, 4 or 8. is that what your question was? marius.
well, it uses 2, as Pd is really 2 applications (pd-gui and pd-core); not big gains however, due to the bad separation between pd-gui and pd-core.
And if an external starts its own thread will it run on another core? Does
in theory yes.
any OS allow a programmer to control which processor the code runs on?
e.g. linux?
sched_setaffinity pthread_setaffinity_np (NPTL-pthreads)
and i just found a linux-journal article: http://www.linuxjournal.com/article/6799
fgmasdr. IOhannes
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
But on the Mac, it's not so hopeful:
"Mac OS X does not export interfaces that identify processors or control thread placementexplicit 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
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
marius schebella wrote:
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?
well, you wouldn't want to do that. you would get a lot of overhead for inter-thread communication, which would decrease performance. as jÃŒrgen has shown in his talk at lac, the optimal number of threads is (not very surprisingly) the same as the number of CPUs the system has.
is it correct that some soundcards compute part of the audio chain on the soundchip? which parts?
well, not within Pd "proper". if your soundcard has a DSP on-board (like the RME HDSP line), you can use it as an additional mixer (you could control the DSP-mixer via acontrol from within Pd - but wouldn't that be "cheating"?)
fgmadsrö IOhannes
Hallo, marius schebella hat gesagt: // marius schebella wrote:
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?
There was an interesting talk about this on the LAC last weekend. It was at the same time as Miller's workshop, so I would recommend to check out the paper: "Exploiting Multi-Core Architectures for Fast Modular Synthesis" by JÃŒrgen Reuter
Recently, CPU speed increases only slowly, while the number of transistors per chip keeps growing exponentially. Consequently, processors with multi-core architectures are pervading the market. Unfortunately, most existing software still can not exploit the parallelism. Since modular software synthesis implementations typically simulate parallel hardware, they are designated to run on parallel hardware. We examine different approaches for parallelization of a modular software synthesizer and discuss their advantages and disadvantages with respect to both the performance gain and the impact on the software architecture.
Paper: http://lac.linuxaudio.org/download/papers/8.pdf Slides: http://lac.linuxaudio.org/download/slides/8/
It is my impression, at least, that on my MacBookPro, the audio engine is running on one core, while the graphics run on the other. I could be wrong about this, but I've never noticed a degradation of audio due to graphics in my setup, and assumed that this was the reason.
Obviously, this is not really parallel processing in the sense we're discussing, but every little bit helps.
Phil Stone pkstonemusic.com
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
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
yes, you're right. sorry, I was not thinking of the gui when I posted my reply, but of course that is an important aspect. marius.
Phil Stone wrote:
It is my impression, at least, that on my MacBookPro, the audio engine is running on one core, while the graphics run on the other. I could be wrong about this, but I've never noticed a degradation of audio due to graphics in my setup, and assumed that this was the reason.
Obviously, this is not really parallel processing in the sense we're discussing, but every little bit helps.
Phil Stone pkstonemusic.com
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
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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:
- 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?
- 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 synthesisAndré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
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
Perfect, thanks a bunch Claude.
So, back to the first message from Marius, what are we going to do
about this?
I regret that I have not yet mastered parallel programming, but would
be game to help out in any way possible (even QA/testing if need be).
~Brandon
On Mar 4, 2008, at 2:38 PM, Claude Heiland-Allen wrote:
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
On Tue, 2008-03-04 at 19:38 +0000, Claude Heiland-Allen wrote:
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.
this probably get's a bit OT, but i really wonder: let's say i am running pd on a multicore box running linux. let's say i run several (two or more) instances of pd in order to distribute the load on several cores, is it possible to run them all on the same instance of jack? if yes, this at least would allow some kind of userspace multithreaded pd.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Am 05.03.2008 um 00:49 schrieb Roman Haefeli:
Besides running multiple copies of Pd, how does Pd scale on many-cpu systems?
It doesn't.
this probably get's a bit OT, but i really wonder: let's say i am running pd on a multicore box running linux. let's
say i run several (two or more) instances of pd in order to distribute the load on several cores, is it possible to run them all on the same instance of jack? if yes, this at least would allow some kind of userspace multithreaded pd.
yes, this is possible by using jackdmp
gr~~~
-
Brandon Zeeb -
bsoisoi
-
Claude Heiland-Allen -
Frank Barknecht -
IOhannes m zmoelnig -
marius schebella -
Martin Peach -
Phil Stone -
Roman Haefeli -
Thomas Grill