Multicore cracks and pops
Oct 16, 2008 at 12:49pm
Multicore cracks and pops
Today I tried my patch on a quad-core cpu, splitting the load between 4 cores. This resulted in a variety of artifacts to the sound; cracks, pops ++.
Im just wondering if there’s a bug when trying to split the load on more than 2 cores? Or am I missing some parameters perhaps?
Any tips are appreciated!
Oct 16, 2008 at 1:33pm
Make sure that you have 5.0.5.
On 16 oct. 08, at 14:49, Hans
Oct 16, 2008 at 2:16pm
I’ll try to build with 5.0.5 tomorrow and let you know if there’s any difference.
Oct 17, 2008 at 9:30am
I have now been testing out the same patch using 5.0.5 and I keep getting some confusing results….
Here are some testdata from both 5.0.4 and 5.0.5 running the same patch on the same quad-core pc, at two different vector sizes.
64 vector size
64 vector size
It appears that the main thread in 5.0.5 carries more of the load in 5.0.5 than it did in 5.0.4.
It also appears that 5.0.5 needs a higher vector size to run reliably than 5.0.4 did when using the parallel option.
I ran this test several times, with reboots of the computer inbetween, and while the cpu-usage stayed the same, the audible result differed. I could not find 1 setting that worked 100% of the times with no audible artifacts.
I also noticed that [parallel $1] does not seem to work in 5.0.5 if [threadcount] is larger than 1. A bug?
Anyway, sorry about the long post.
I think I might have to stay with Max4 for the time being with this application, as I don’t seem to get any advantage of using multiple cores, and the added cpu strain in Max5 isn’t worth it if only using one core… for this patch at least.
Nov 8, 2008 at 7:40pm
Were you able to find any resolution to this issue? I am having similar problems with Max 5.0.5 (and earlier versions too I think, about to test with 5.0.4 and 5.0.2 when I have a chance) with OS X 10.5.3 on a dual core and octo core machine. I’ll try to most some more detailed information later.
Nov 10, 2008 at 9:52am
I have put the whole idea of parallelism on hold for now, waiting for updates on this. Am currently using Max 4.6 running the same patch on one core. Works reliably and at a much lower cpu-load than the same patch on the same computer under Max 5.0.5.
Let me know if you find a fix to it though!
Nov 10, 2008 at 5:36pm
This all sounds about right to us. We’re guessing that the testing patch being used does very little processing and has many out~ objects. This case just isn’t going to improve any time soon, and you’ll need to find another strategy to solve the problem.
The major change in 5.0.5 is that out~ objects no longer accumulate into the same memory. For thread safety reasons (which on many newer processors, led to clicks), they need to be accumulated into the final output memory from the main DSP thread. This means that where there isn’t much computation inside a single voice, but *many* out~ objects and *many* voices, the accumulation in the main DSP thread will outweigh the CPU which can be offloaded to the other threads. Other situations which there is heavy computation within a single voice and a handful of out~ objects should notice only minimal impact with this necessary change.
The other thing which this implementation requires is that the DSP must be restarted for the parallel message to take effect, so that all the out~ objects can be initialized properly.
Nov 10, 2008 at 6:42pm
Quote: Andrew Pask wrote on Mon, 10 November 2008 12:36
So does that mean that if I have one of those newer processors, running an older version is not a legit solution because it would be “unsafe”?
> The other thing which this implementation requires is that the DSP must be restarted for the parallel message to take effect, so that all the out~ objects can be initialized properly.
I hadn’t been using the “parallel” message, but the @parallel attribute. Does that mean it is worth trying sending the message and cycling DSP? I had given up for now (at least until after my gig on Thursday) and was just trying to be more efficient in my synthesis/use less instances. Is it worth trying the message vs. the attribute when I get home tonight?
Nov 10, 2008 at 7:03pm
>So does that mean that if I have one of those newer processors, running an older version is not a legit solution because it would be “unsafe”?
>I hadn’t been using the “parallel” message, but the @parallel attribute.
Nov 11, 2008 at 2:57am
Thanks for the quick response! I guess I’ll go easy on my poly-FFT for now.
Nov 11, 2008 at 8:18am
I figured it might be something like that causing the overhead in the main thread.
Perhaps I didn’t restart my dac when changing the settings, and that it was using some older settings I had tried… I didn’t really think about that seeing as the cpu load changed instantly when changing the settings when the dac was on.
You are right in thinking the test patch has lots of ins and outs, and fairly low computation in each voice. I will see if there’s any way of restructuring this to make use of [parallel] but there’s no really obvious solution.
Thanx for clarifying this though, I appreciate it!
You must be logged in to reply to this topic.