KVR :: MeldaProduction » [MXXX] Multicore Support? [View Original Topic]
There are 15 posts in this topic.
Satch1 - Tue May 01, 2012 8:07 am
Hello Vojtech, just wondering if you are planning on bringing multicore support to MXXX at some point? It would defo come in handy.
MeldaProduction - Wed May 02, 2012 4:31 am
Hi, what you mean by that? You mean processing in multiple threads? Absolutely NOT! Not that it would be that hard, it's in conflict with host's processing! I can see like many companies like NI or IL use the multithreading, but it's just a trick actually! It relieves your CPU for small projects used for performance testing and it also makes all CPU meters virtually useless (because they just cannot measure what they don't have access to), so you think it is faster, but when the project gets bigger, it will collide with the host's native multithreading and will probably take more CPU than necessary and may even cause lags due to all the thread switches.
The only reasonable usage of multithreading is for convolution reverbs, where it just cannot be computed in each frame, and may be some other large block processes.
Satch1 - Wed May 02, 2012 4:05 pm
MeldaProduction wrote:
Hi, what you mean by that? You mean processing in multiple threads? Absolutely NOT! Not that it would be that hard, it's in conflict with host's processing! I can see like many companies like NI or IL use the multithreading, but it's just a trick actually! It relieves your CPU for small projects used for performance testing and it also makes all CPU meters virtually useless (because they just cannot measure what they don't have access to), so you think it is faster, but when the project gets bigger, it will collide with the host's native multithreading and will probably take more CPU than necessary and may even cause lags due to all the thread switches.
The only reasonable usage of multithreading is for convolution reverbs, where it just cannot be computed in each frame, and may be some other large block processes.
The only reasonable usage of multithreading is for convolution reverbs, where it just cannot be computed in each frame, and may be some other large block processes.
Hi Vojtech, yes multiple threads. I only ask because u-he's Diva has just been updated to include multi-threading and it works great, but (as I've just discovered), only when running one instance. Like you say, when you start adding more instances, all with multi-threading enabled, they actually use more CPU than without it enabled. I can see now why you wouldn't want to include it in MXXX. Thanks for explaining.
abstractcats - Wed May 02, 2012 4:32 pm
Satch1 wrote:
MeldaProduction wrote:
Hi, what you mean by that? You mean processing in multiple threads? Absolutely NOT! Not that it would be that hard, it's in conflict with host's processing! I can see like many companies like NI or IL use the multithreading, but it's just a trick actually! It relieves your CPU for small projects used for performance testing and it also makes all CPU meters virtually useless (because they just cannot measure what they don't have access to), so you think it is faster, but when the project gets bigger, it will collide with the host's native multithreading and will probably take more CPU than necessary and may even cause lags due to all the thread switches.
The only reasonable usage of multithreading is for convolution reverbs, where it just cannot be computed in each frame, and may be some other large block processes.
The only reasonable usage of multithreading is for convolution reverbs, where it just cannot be computed in each frame, and may be some other large block processes.
Hi Vojtech, yes multiple threads. I only ask because u-he's Diva has just been updated to include multi-threading and it works great, but (as I've just discovered), only when running one instance. Like you say, when you start adding more instances, all with multi-threading enabled, they actually use more CPU than without it enabled. I can see now why you wouldn't want to include it in MXXX. Thanks for explaining.
I did not realize this! So might as well turn off Multithread processing and get the fastest CPU you can afford?
MeldaProduction - Thu May 03, 2012 2:10 am
No no! The idea is - the host uses the available cores. It detects number of available cores and creates a processing thread for each (minus one for GUI). Of course the host may not be able to use all of them - e.g. if you have 8 cores and only 4 tracks (only separate tracks can be optimized, well, it's not that simple, but let's say it is...), then there would be 3 cores available, but there's no way for the plugin to find out and also this situation is rather rare
. So simply put, the plugin should not mess up with the processing maintained by the host. tony tony chopper - Thu May 03, 2012 2:37 am
Quote:
I can see like many companies like NI or IL use the multithreading, but it's just a trick actually! It relieves your CPU for small projects used for performance testing and it also makes all CPU meters virtually useless (because they just cannot measure what they don't have access to), so you think it is faster, but when the project gets bigger, it will collide with the host's native multithreading and will probably take more CPU than necessary and may even cause lags due to all the thread switches.
Except that the host doesn't necessarily have enough to process. Not everything can be run in parallel. Take the effects in your master track (how is that "rather rare"?), what else can you process along with them?
Also, a plugin knows more about itself than a host about plugins, so can do more efficient multithreading.
Now, that's only for plugins that are already CPU-costy. If a plugin doesn't already suck enough CPU, multithreading is only gonna eat more CPU. & that's the whole problem with multithreading at small latencies.
Quote:
and may even cause lags due to all the thread switches
Not if done properly.
You don't have to wait for side threads to be done processing, you have to wait for everything to have been processed. If all cores are busy (very unlikely but why not) then most likely your side threads won't even get the time to wake up, you'll be done processing in your first thread.
And in any case: yes it has to be a switch, for the user to decide.
MeldaProduction - Thu May 03, 2012 6:53 am
Sure, good points. But it's a little more complicated. I think you are basically talking about FL, because that's your host and plugin, right? The thing is, each host implements the multithreading different way. (Please don't take this personally - I found that FL's CPU comsumption reported by its own meters was often as high as 10x higher than Reaper's for example, no idea why, just an observation when I was checking some performance stuff)
Also Macs work different way than Windows. Since the master of the whole process is system's scheduler, which may just work different way than you assume, multithreading will work against you in most cases (except for the mentioned convolution and similar, where the big blocks just don't give you any other option).
From my experience, people often use as much as 50 tracks per project. Assuming 8 cores and some more complicated routing, the DAW has to schedule them carefully one track per core and go to the next one when finished. Then imagine you have a plugin on one of the tracks (let's say the last one to make things worse) that wants to "optimize" by subprocessing in say 4 additional threads (to make things more obvious). Then at the moment the plugin starts processing all available cores are already taken, so it must wait. After that it runs the 4 cores, which means the host cannot use to anything else (in our case it is waiting anyway), and it will probably even end up with other cores idle, because the host has just nothing else to do. And if you finish in time, it can finally start processing the mastertrack. And this is just the simple scenario.
Let's rather not talk about potential master track subblock parallelization, which I'm not sure if and by which hosts it is used.
It's just not simple at all and one can end in a nasty conflict and an on/off switch is not the cure, because the conflict may not happen immediately, but only in some specific situations... (it's kind of my field, that's why I'm talking about that so much
) tony tony chopper - Thu May 03, 2012 7:23 am
Quote:
From my experience, people often use as much as 50 tracks per project.
But (well, in FL) they're rarely in parallel, they're often mixing into each other.
Also you have to take into account
-plugins that lock themselves too much, for too long
-plugins that are not multithreadable & either lock their processing entirely or worse, don't do it & assume the user will
That's all I've noticed, it's easy to make a benchmark song that uses all cores at their best, but in practice it's never the case and there's never enough to keep all cores busy.
Better have too much to process in parallel than not enough.
Quote:
Assuming 8 cores and some more complicated routing, the DAW has to schedule them carefully one track per core and go to the next one when finished.
I don't agree, the sequencer shouldn't assign threads to cores, it should let the OS do that, the OS knows best. To start with, what would you do with hyperthreading? Those appear as "cores", but aren't real ones, and it would be pretty bad to force threads on them, and it would be pretty bad to do nothing with them too.
MeldaProduction - Thu May 03, 2012 7:35 am
Well, obviously there are arguments for and agains and since I don't have much time right now, let's finish it as "you are for multithreading and I'm against"
tony tony chopper - Thu May 03, 2012 8:01 am
that's because there are arguments for & against that I made it optional
(& a couple of years ago I was here in this forum, arguing against, too saying that it's better left to the host. But there's theory & practice, & it really depends on the plugin's ability to do it efficiently)
MeldaProduction - Fri May 04, 2012 1:26 pm
Ok Tony, I have a really weird thing here, which reminds me this conversation.
I'm testing my vocoder for MXXX in Reaper, and I downloaded several other vocoders for inspiration, including Vocodex. And here's the interesting thing - my plugin currently shows 4% CPU usage with some settings. Now when I add Vocodex to any track in Reaper, it increases to 8% and it even stays there when I unload Vocodex! So I started checking other plugins and no other plugin I have here does that, interestingly except for Maximus (so maybe all your plugins?). And the weirdest thing is this: when I unload your plugins and load Voxengo's CurveEq it gets back to normal!!
Any ideas?? Seems like your plugin changes some system settings, thread priorities? I also use IPP and I guess you are using it too, so maybe something related to that?? tony tony chopper - Fri May 04, 2012 2:24 pm
You mean YOUR plugin increases its CPU usage or Vocodex does?
Things to try:
-soundgoodizer level to zero in Vocodex (shouldn't make a difference unless the input is filled with low noise & the auto-bypass can't detect it as silence)
-switch "threaded" off (but I doubt it's the cause)
MeldaProduction - Fri May 04, 2012 4:10 pm
I meant "my plugin" increases CPU usage, that's the weird thing. So far the only thing that seems to trigger it is Vocodex / Maximus instance. No idea what the hell is that...
tony tony chopper - Fri May 04, 2012 11:22 pm
don't you monitor your CPU usage yourself btw?
MeldaProduction - Sat May 05, 2012 10:19 am
I usually use the Reaper's CPU meter as it is quite accurate. But I'll check. Thx for response.
There are 15 posts in this topic.