Multicore? Why not?

VST, AU, AAX, etc. plug-in Virtual Instruments discussion
BrokenTrance
KVRist
257 posts since 25 Nov, 2010

Post Sat Nov 10, 2018 4:45 pm

Hay.

I tried d 16 group synth and i have also tried u-he Diva. Both this have multicore disabled in initial state. But why? Is it compatibility issues?

Thank.

ScottZ
KVRist
263 posts since 19 Feb, 2011

Re: Multicore? Why not?

Post Sat Nov 10, 2018 4:58 pm

hmm idk maybe because if default could make performance worse. I remember on my old core 2 duo it did. If it was on by default users who don't bother to turn off might think plugin is unoptimized crap. Easy to change settings, d16 saves your settings and diva is a button for those who want it.

acYm
KVRian
707 posts since 11 Sep, 2015

Re: Multicore? Why not?

Post Sat Nov 10, 2018 5:24 pm

sometimes in manuals it says like, depending on system configuration and other factors, enabling multicore may actually decrease performance. not that I've ever seen that myself but I'd guess that yes, if it's not enabled by default it's for compatibility purposes of some sort.

BrokenTrance
KVRist
257 posts since 25 Nov, 2010

Re: Multicore? Why not?

Post Sat Nov 10, 2018 5:28 pm

Ok got it lads. Thanks.

User avatar
jancivil
KVRAF
15811 posts since 20 Oct, 2007 from No Location

Re: Multicore? Why not?

Post Sat Nov 10, 2018 5:34 pm

The issue is more down to using it in a host where multicore distribution is enabled, both enabled creating some conflict.

BrokenTrance
KVRist
257 posts since 25 Nov, 2010

Re: Multicore? Why not?

Post Sat Nov 10, 2018 5:37 pm

Really, jancivil? Thanks for your input.

User avatar
EvilDragon
KVRAF
17080 posts since 7 Jan, 2009 from Croatia

Re: Multicore? Why not?

Post Sat Nov 10, 2018 11:44 pm

Multicore usually works fine with a couple of instances of the same multicore-enabled plugin, but once you start approaching a larger number of instances of that same plugin, there's a lot more chance for above mentioned conflicts to happen (instances "fighting" for cores). That's why it's disabled by default. For simpler/monophonic sounds, usually you don't need multicore enabled, for polyphonic, you might. Gotta pick your battles.

mystran
KVRAF
5001 posts since 12 Feb, 2006 from Helsinki, Finland

Re: Multicore? Why not?

Post Tue Nov 13, 2018 12:09 pm

EvilDragon wrote:
Sat Nov 10, 2018 11:44 pm
Multicore usually works fine with a couple of instances of the same multicore-enabled plugin, but once you start approaching a larger number of instances of that same plugin, there's a lot more chance for above mentioned conflicts to happen (instances "fighting" for cores). That's why it's disabled by default. For simpler/monophonic sounds, usually you don't need multicore enabled, for polyphonic, you might. Gotta pick your battles.
Actually multiple instances of the same plugin can pretty easily avoid "fighting for cores" just by using a shared thread-pool and submitting all the jobs from one instance in bulk (which is often really simple to do in practice if your multi-threading is something like "voices in parallel"). It's more of a problem with different plugins, although the host itself also counts, since it's usually multi-threading as well. That said, I personally don't think "fighting for cores" is really such a huge problem when running at the reasonably short latencies most people would go for in audio (ie. the scheduling quanta required are short enough that it's unlikely the scheduler will switch threads around too much). In fact some over-commitment actually helps with keeping all the cores busy, so they don't need to sit idle while you're trying to schedule more work for them.

The important thing to keep in mind though is that multi-threading has some inherent cost of it's own, both in terms of CPU and in terms of wall-clock time, since sending a job to another thread for processing is not free. When you have a lot of cores and multi-threading a plugin allows you to keep all these cores busy (or busier) when they'd otherwise be sitting idle (eg. the host can't schedule enough parallel jobs on it's own), you tend to get large enough speedups that the overheads are basically irrelevant. On the other hands, when you only have a few cores and/or the host can already keep all the cores busy anyway, you're effectively paying for the overhead without getting any of the speedup.

It's a little (well, actually a lot) more complicated than that in practice (with no optimal solution available in practice), thanks to scheduling considerations with the signal processing graph down the line, but the important thing to keep in mind is that multi-threading is always slower in terms of "total processing time" and you only get a speedup when the core utilisation improves (ie. you're doing more of the stuff in parallel). If your core utilisation is already as good as it's going to get (eg. all the cores are busy anyway), then you're only going to get a slowdown. This is likely to explain many of the situations where old CPUs with only a few cores don't seem to get any benefit while newer ones generally do.
If you'd like Signaldust to return, please ask Katinka Tuisku to resign.

Return to “Instruments”