why does ace only eat on one core ( CPU )?

[jupiter8]

Of course it's possible to run a plugin on multiple threads like for example running each voice on a separate thread. Not only is it possible it is being done. NI Kontakt for example does this (not per voice,i highly doubt that).

But Kontakt is a completely different matter. You could say it is a VST host itself since it is multi timbral.

You need to look at the system as a whole. Of course you could run each ACE voice on a separate thread but it would be very inefficient. True you could run more voices on a single instance but what if you had several ? Then it would be even CPU heavier than it is today. Multi threading doesn't lower the CPU consumption,it raises it. So there is little point in multi threading ACE if you ask me.

of course, bot one could offer it as an option, for heavy patches and realtime uses.

Yeah you could but i assume it would be a lot of (likely error prone) work so how much are you prepared to pay for it ? The low price is one of it's main selling points.

[EvilDragon]

There are some plugins which utilize multicore processing in a good way. Alredy mentioned Kontakt and RP plugins. Another honorary mention is Pianoteq - it does multicore processing very efficiently, and without any noticeable additional latency. So Urs - you might want to add multicore processing as an option to your CPU-munching plugins. Some people might use it to a good purpose!


Please?

[raikard233]

Check out also this page:
http://macperformanceguide.com/Reviews- ... mates.html

Seems that in the real world the "dual 4-cores westmere" and the "single 4-cores nehalem" have almost the same performance, but with different costs.
The point will then go to the RAM amount that you can put on it, 64gb on the dual system and 32gb on the single system.
Maximum ram amounts that are so far away from my needs at the moment!

[tony tony chopper]

and without any noticeable additional latency.

The latency (there is one) will translate into wasted CPU. In short, to release sleeping threads it has to enter kernel mode, and that takes time (waiting). Thus when you multithread, you waste CPU, and the idea is that the CPU you spare by multithreading has to be higher than the one you waste.
For plugins it's not as bad as you'd think, because the workload is pretty even. It can work "well" as in a benchmark, while a host can work well in a benchmark and in practical projects be less efficient with multithreading than without. In short, a host has to multithread pieces of code that it knows nothing about (plugins) while a plugin can multithread something it knows about, and that's an advantage.

[dasdeck]

Of course it's possible to run a plugin on multiple threads like for example running each voice on a separate thread. Not only is it possible it is being done. NI Kontakt for example does this (not per voice,i highly doubt that).

But Kontakt is a completely different matter. You could say it is a VST host itself since it is multi timbral.

You need to look at the system as a whole. Of course you could run each ACE voice on a separate thread but it would be very inefficient. True you could run more voices on a single instance but what if you had several ? Then it would be even CPU heavier than it is today. Multi threading doesn't lower the CPU consumption,it raises it. So there is little point in multi threading ACE if you ask me.

of course, bot one could offer it as an option, for heavy patches and realtime uses.

Yeah you could but i assume it would be a lot of (likely error prone) work so how much are you prepared to pay for it ? The low price is one of it's main selling points.

of course...i don't use the software or know the code so i can not tell how much work it would be. simple, non interacting voices should be not that hard thougth.
anyways does not matter to me really. i can image there is quite some interaction between the voices. it just sounded that it was not possible in general, this is what i was trying to adress. whether it is worth it is of course not up to me to decide or judge

cheers!

jm

[EvilDragon]

and without any noticeable additional latency.

The latency (there is one) will translate into wasted CPU. In short, to release sleeping threads it has to enter kernel mode, and that takes time (waiting). Thus when you multithread, you waste CPU, and the idea is that the CPU you spare by multithreading has to be higher than the one you waste.

Could be. I just know that when Pianoteq is in non-multithreading mode, CPU skyrockets. So they DID make it work much better than if they'd utilize just a single core. Paired with a great multi-threading DAW (Reaper), it's a match made in heaven.

[Nielzie]

In short, a host has to multithread pieces of code that it knows nothing about (plugins) while a plugin can multithread something it knows about, and that's an advantage.

Interesting, so do you think a cpu hungry plugin like for instance Sawer could benefit from it?

I choose Sawer as an example here because you probably know a lot about its internal processing But it could of course be the same case with ACE or in general.

[tony tony chopper]

I choose Sawer as an example here because you probably know a lot about its internal processing

Sawer was made by Maxx, I know nothing about it. But I made Harmless/Vocodex which have multithreaded processing (they have a switch to compare).

I just know that when Pianoteq is in non-multithreading mode, CPU skyrockets.

how much better? On a quad core you might expect 3x better performances, but that's if the plugin already eats a lot of CPU to start with. Again, if you try multithreading a very light plugin, it's gonna be less efficient.

[EvilDragon]

You meant to ask how much WORSE. When multithreading in Pianoteq is deactivated, it consumes up to 50% times more of the CPU, depending on the CPU!

[tony tony chopper]

When multithreading in Pianoteq is deactivated, it consumes up to 50% times more of the CPU, depending on the CPU!

as someone already explained, multithreading will eat more CPU, the CPU required to handle the multithreading. But summed CPU usage of all cores in the task manager and "CPU until audio underruns" are 2 totally different measurements, and only the CPU until underruns matters.

That said, you can ALSO eat more CPU in the "CPU until underruns" when multithreading, if the CPU wasted for the multithreading is higher than the one spared by multithreading, which is the case if you're multithreading a couple of very light plugins alone.