Additional CPU core fails to improve performance

[lallis]

I came across a triple core "Phenom" CPU of similar clock speed to my old dual core. Using it, I expected to see some drop in the Cantabile "Load Percentage" meter due to increased CPU capacity, but the result has been backward.

Ivory's player uses essentially only one core, but it reports the best (lowest) Load Percentage of all the models I have, unchanged from before.

The Aria sampler that runs the Garritan Authorized Steinway reports VERY slightly lower numbers with this new CPU (probably an insignificant change), although it still uses only 2 cores. This is a low-load sample in Cantabile with any CPU.

Galaxy II pianos in Kontakt levels out the usage much more equally across all three cores, but the Cantabile Load Percentage goes up noticeably (+15-20%) after adding the third core. The Galaxy pianos still play all right, but frequent spikes well over 100% are now common at the same sample buffer levels as I used before. Galaxy has been a medium-usage sample previously, running 40-50%. Now 55-70% with extreme spikes.

I accept that the different samplers themselves are probably controlling the core usage. But why the inverse ratio? Surely using one core cannot give Cantabile better performance headroom than using two or three. And why does none of it seem to make any actual difference? In practice, the pianos play the same as ever now.

I have tried Compatibility and Aggressive core usage modes. Results are about the same. The Load Percentage is more of a mystery than ever.



EDIT: Load-up time for the samples is noticeably (maybe 15-20%) reduced, so my extra core is showing some improvement there. Windows in general runs a little snappier. Even Canatbile shuts down faster now. It's only the Load Percentage that discovers a reduction in performance.

[TiUser]

Cantabile can only use more than one core if you use plugins in more than one rack. If you only load one piano plugin (or multiple plugins in one rack) you will not benefit from multiple cores - at least if the plugins do not support multiple cores... and if, switch off Cantabiles multiprocessing first to see how the plugins options behave...

Hope this helps.

[lallis]

Thanks, TI! That is an unexpected (and unhappy) answer. It never occurred to me Cantabile could function so. I wish it did not.

I have so far used only single-rack sessions, and they do act in accordance with what you describe.

Well, at least there is a direction in which to start searching for a performance improvement.

Thanks again.

[TiUser]

Indeed it's not that easy to benefit from multiple core cpu's. Many of today's software hardly use two cores.

The problem for the developer is to identify tasks that can be performed in parallel without needing to wait for each other. When you chain let's say a VST instrument and a reverb the latter can start processing only if the instrument has already calculated it's buffer. To do this in parallel is not possible. Maybe it can be interlaced, i.e. instrument buffer 2 is calculated while reverb buffer 1 is processed... but that's not easy and triccy. Another thing is that - as far as I know - you can't directly assign threads to a core in windows (as you can't allocate physical memory...) - windows schedules this and as win is no real time os timings can't be guaranteed in any way. Hence there are more problems to fully use the available cpu power. I am also in doubt if the new processing boost feature in core i3/i5/i7 cpu's will better anything for music software...

But not all is bad with multicore for music...

Some plugins itself do internally support multiple cores. There is also less interference when you run other programs beneath Cantabile. But I agree, developers have to face this new multiprocessing capabilities in pc's and make better use of it. But don't expect wonders either, we have might have 4 or more cores, but no 4 or more independent ram banks and other peripherals, so there is also always the problem of sharing resources... it's not that easy as 4 cores quadruple processing power... unfortunately. Higher clock speed is still the only reliable performance booster for any type of program...

If you are into digital photography I recommend checking out "bibble 5" raw converter... it's highly parallel and surpasses all other similar applications when you have 4 or more cores in your system.

Video applications also benefit a lot from multi core when encoding video. You can monitor this with the task manager or other cpu tools.

It's easy to imagine how this works, just load computing of each image or frame on one core and you get a nearly linear speed boost - but these decoding / encoding are usually no realtime synced processes...

If you remember something older called "SSE" and "SSE2", this is parallelism on a single core... special cpu commands that process 4 data values at a time. So imagine a synth that can produce 1-4 voices at the same cpu cost while the 5-8 will double cpu load... computing gets really complicated these days...

To finish with some practical idea, one can experiment with the new additional buffers feature too... and to quote Brad, basically 1+1 128sample buffers perform better than a single 256 sample buffer.

[lallis]

What an excellent explanation of the problem! It's very kind of you to do all that work.

I see now that I was expecting too much and not thinking clearly enough.

[TiUser]

I see now that I was expecting too much and not thinking clearly enough.

I don't think so... it's just difficult to understand the complexity - and I am also only able to scratch the surface.

Cpu makers promise a lot but it gets more and more difficult to understand the advantages...

[contrary]

Fascinating stuff .... But does cause a little brain hurt !!!

The current semi-conductor technology has reached it's limits as far as core speed ( w/o serious cooling schemes) so that's why the consumer PC has gone to multi-core ... programmers probably wish they hadn't !!

[TiUser]

..well, multicore seems indeed to be the easier way for silicon makers.

But multicore isn't bad design wise - just windows isn't a realtime operating system. I guess it's much less critical to schedule non realtime processes and threads across cores. When you examine windows task manager you will always find more processes than cores - so there's still enough headroom to sell xx - core machines

I think there can be done a lot more design wise - even without increasing speed a lot over 3GHZ or so... basically doubling speed means quadrupling power dissipation, so there are indeed limits. Only chance is to decrease supply voltage, which is limited too according to the way silicon elements work...

The usual design in pc's is "von Neumann" structure - which basically means having program code and data in the same memory. Compare to Shark DSP design which uses the "Harvard" structure - basically separating program code from data memory, resulting in the capability to fetch code commands and data in parallel - resulting in better performance and flexibility.

I already mentioned the resource problem... unless each core has enough own memory you always run some time into resource conflicts. Another problem is memory speed and dram is by far inferior to the core - hence the effort with caches...

Finally I agree, without a radical shift in technology we most likely will see more and more cores instead of higher clock rates in single cores.

[TiUser]

EDIT: Load-up time for the samples is noticeably (maybe 15-20%) reduced, so my extra core is showing some improvement there. Windows in general runs a little snappier. Even Canatbile shuts down faster now. It's only the Load Percentage that discovers a reduction in performance.

Looks like I missed this...
I guess this is not caused by an extra core but better other resources like a faster hard disk and probably faster ram. Just to focus on the cpu doesn't make the cake... and to be honest: I still don't understand how to optimally configure a pc for maximum audio performance.

[lallis]

...I guess this is not caused by an extra core but better other resources like a faster hard disk and probably faster ram...

Nothing was changed in the computer except for the CPU. However, after more time to experiment, I believe now that I overestimated any improvement in loading time. It did seem faster. I could not prove that by measured times, and I would not be surprised if it proved a false impression. Windows in general runs somewhat more crisply, but it's not an important improvement.

The corollary of your original point was good: Don't waste your time adding cores, in order to play Cantabile instruments. Had I spent more than a risibly small amount, I would feel annoyed. Actual improvement might be realized by changing to a much faster single-core. Since those are unfashionable now, very low prices are easy to find on used ones sold by recent upgraders.


To recover performance, I have done a radical, high-voltage overclock. That has been successful. Because it cost me only $40, I don't care if I ruin this CPU with high voltage.

[TiUser]

Ok, clocking higher will always give a boost.

When I bought my latest machine I asked myself either to go for dual core (with higher clock) or quad core (with more decent clock)... I went for the quad core but finally I've mixed feelings about this decision.

For video and imaging with the right software it's definitely thumbs up.

For Cantabile higher clock rate would have been a better choice - as long as you do not use many racks in parallel. But even in the latter case many cores are not as effective. So my experience is based on a pretty average machine - not optimized for audio in any way.

Probably things change with the new i core machines... but my personal conviction is it needs longer than 2 years in the run to get a real practical boost... so lets discuss this again in maybe 5 years, or 10...

[bradr]

I just wanted to add a few more notes to TiUser's good summary above.

There are many other things going on under the covers that will leverage additional cores, besides the straight audio processing pipeline. For example there are background worker threads in Cantabile that zero audio buffers in preparation for the next audio cycle, mp3 and wave file reading and decoding threads, audio driver and buffering threads, the UI itself and more. So while an additional core might not lead directly to an improvement in the load meter, the overall system will run more efficiently because you have additional cores to handle these background tasks and because there's less thread context switching.

Also, real-time audio is a very different problem to tackle than non-realtime processing and there are reasons you don't get the direct 1 to 1 performance boosts that something like audio or video rendering can yield. The main difference is the fact that with audio we're continuously trying to do lots of little bits of processing as quickly as possible (ie: each audio buffer is typically < 10ms) and we want that done asap. With something like image/video rendering or offline video transcoding there's a large body of work that we just want finished asap - we don't care about results being delivered along the way.

This slicing of the work into small parts has significant impact because there's a time cost overhead involved in pushing work off onto another thread. With offline processing, the job can be split in two (or more) large parts and each part given to a different thread (ie: core) and when all the parts are finished, the job is done. In this case the cost of the thread switch is negligible in comparison to the large amount of work involved.

With realtime, things aren't so simple and that continuous repeated overhead of pushing work off to worker threads comes into play. The ratio of work to be done vs overhead of thread switching changes radically.

Take a simple example. Suppose you have a session setup with two racks, one VSTi in each and suppose plugin A is very lightweight, while plugin B is not. What Cantabile will typically do in this case is try to process each rack on a different thread (ie: core). So Cantabile wakes up a worker thread to process plugin B (the heavy one) and while it's doing that the main audio thread processes plugin A. Plugin A finishes processing quickly (cause it's lightweight) but what then?

Cantabile can sleep the main audio thread and ask the OS for a wake up when plugin B finishes (which reduces Task Manager's CPU load), but depending on how much work is left on plugin B, this may actually take a longer since the sleep/wakeup process has overhead.

Alternatively, Cantabile can spin a busy loop waiting for plugin B to finish, which burns CPU but may result in a faster final result. In this case you'd think faster is better but actually this approach takes away processing power from other threads and also consumes more power (reduced battery life).

Throw into this the fact that Cantabile doesn't know which plugins are heavy/light to process, the fact that the processing load of a plugin can change significantly from one cycle to the next (eg: as notes in a VSTi a pressed/released) and the fact that there can be many racks all with different loads and you start to see how complex this can get.

The other thing to note about the above example, is that plugin A now has "hidden headroom". The time while it's waiting for synth B could be used to process additional notes/effects without causing any increase in the load meter, since it will still probably finish before plugin B.

In summary, while throwing in an extra core might in fact increase the load meter you probably have additional hidden headroom, better stability and overall better performance.

Brad