Multicore? Why not?
-
- KVRian
- Topic Starter
- 612 posts since 25 Nov, 2010
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.
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.
-
- KVRist
- 308 posts since 19 Feb, 2011
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.
-
- KVRian
- 1185 posts since 11 Sep, 2015
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.
-
- KVRian
- Topic Starter
- 612 posts since 25 Nov, 2010
Ok got it lads. Thanks.
-
- KVRian
- Topic Starter
- 612 posts since 25 Nov, 2010
Really, jancivil? Thanks for your input.
- KVRAF
- 23069 posts since 7 Jan, 2009 from Croatia
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.
- KVRAF
- 7852 posts since 12 Feb, 2006 from Helsinki, Finland
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.EvilDragon wrote: ↑Sun Nov 11, 2018 7:44 am 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.
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.