CPU load in comparison

[tulamide]

I wonder for quite some time now, but never got a satisfying answer. As you might have noticed, I'm having trouble using Spogg's Quilcomm Monster Synths. They show a cpu load of 40% even when only playing a chord. This is due to a lot of functionality inside and I accept that.

But...

Here is a small 8-bar loop played twice. It is taken directly from Reason, no mastering, so be careful when hearing it.
example.mp3

It might not sound like much, but there's a lot going on. In total there are 12 synths playing simultanously.
- 5x SubTractor (Image Link)
- 3x Malström (Image Link)
- 2x NN-XT (Image Link)
- 1x Thor (Image Link)
- 1x ReDrum (Image Link)

Also, without a detailed list, another dozen of effects, like reverbs, delays, chorus, flanger, gated envelope filter, compressor, amp distortion, etc.

All of this used simultanously in that loop. And while playing the task manager shows a cpu load of 13% (!!!) for Reason - that's including the editor and all its animated images.

How, I really don't understand it, how did they do that? I can run (I'm serious) over 100 SubTractors playing simultanously. Is it black magic? Are they by far the worlds most talented audio programmers? Or is there a trick, that I could use in Flowstone as well?

How, just how?

[KG_is_back]

The CPU meter in Flowstone shows only the CPU load of streams (and possibly some ruby, if frames are used). The stream part of the schematic is executed only in one thread. The actual value on the FS CPU meter is the percentage of the computing power that your operating system reserved as maximum for the Flowstone-Streams-thread (warning: not the actual name of it). 100% means, the Flowstone uses all the computing power your operating system is willing (or capable of) to give it.
The Task manager shows the percentage of the maximum computing power of your particular machine ( =100% means all of the cores on your machine are running at 100%, being busy all the time).
Example:
I have intel-i5 dualcore (4-thread) CPU. If I create Flowstone schematic that uses 100% on its internal meter, the task manager shows 25%. The operating system gives it the full power of one core (half of it - intel cores use hyper-thread technology, which basically presents each core as two cores to your operating system). It is physically impossible to give it more, unless you split the stream processing into more threads (which is not possible and frankly completely unnecessary in FS).
If I create schematic that uses very little CPU power, It is likely that Operating system will reserve it much less CPU power than the physical maximum - the meter in FS will show much higher values, than what the real limit of your computer is. On my machine particular, OP reserves (twice) more power once the schematic exceeds 50%, so I observe sudden drop to 25% every time that happens until all power is wasted.

In your example with multiple synths, Reason runs the plugins on separate threads, spreading the load across multiple cores. It also probably uses graphical accelerator for its GUI part (and many plugins' GUIs do that too), which is not even tracked by Tasked manager. The meter shows 13% because that's exactly how much of your total CPU power are really using. To make the test more relevant, try adding a few Quilcomms to the game, to see how they affect the load in real comparison. I'm sure Spogg would not mind having his synths tested this way.

Internal FS meter showing 40% may simply mean, that your OS is very possessive about it's CPU resources and relies on its ability to adjust individual threads' headrooms on fly very fast. Which is kind of one of its main jobs


On the actual question about Flowstone's CPU performance. Flowstone is not exactly the best tool for making CPU optimized synths. Not because it's badly programmed, but because of the limitations of its basic design. Sample by sample processing, namely. The way FS works, it compiles the stream part into a single "function". Then calls that function once for each sample in the buffer. Also, mono and poly streams need to stay in sync (you can pass data continuously from one to another), so they are both executed inside that "function". If you want to process something truly in parallel, you need to use frames and DLL (either in ruby or DLL component) and Flowstone needs to buffer the data between stream-thread and the DLL-thread (creating latency of the size of one buffer).
All of the above-mentioned issues can be circumvented by carefully designing your plugin/app in C++ (by making it work completely differently than Flowstone does). For example memory-pre-fetching may be improved by splitting the processing part into smaller stages (each stage processing the buffer as a whole).

Things you can do to optimize Streams in Flowstone (in descending order of efficiency):
1. Use selectors to disable parts that are unnecessary.
2. Move as much of the processing into green as possible.
3. Use HOP in your Code components to minimize unnecessary processing.
4. Optimize code in assembler and/or use modules that are optimized already.
5. Give up and make stuff that is so awesome, people will use it despite its CPU hunger.

[Spogg]

Fascinating!

I was dissapointed that tulamide couldn't get to play with some of my stuff. At least I got some feedback!

Here's a test on my PC; core i7, Windows 7 SP1 32 bit, 8 meg DDR3 (3.7 meg for 32 bit Windows) Creative X-Fi on ASIO

Spectre 1.11, residual (not playing) and 7 note chord, Preset 1 (Stacey)

Spectre running in Flowstone
Residual 6.7%
Chord 19.1%
Task Manager CPU residual 0-4% varying
Task Manager CPU chord 1-5% varying (i.e +1%)

As VSTi in Reaper 5.1with monitoring in Record enabled mode (not recording)
Residual 0.9% / 0.9% (Reaper CPU meter)
Chord 2.3% / 2.3% (Reaper CPU meter)
Task manager CPU residual 1-5% varying
Task manager CPU chord 2-7% varying (i.e. +1%)

I chose not to use selectors for the partials so if the synth worked on any preset it would work on all and also the complexity would be reduced.

Cheers

Spogg

[tulamide]

@Spogg
I hope you don't mind that I mentioned your synths. I could have taken any other VSTi as well. I always experience a much higher CPU load with VSTis compared to Reason. It is most obvious whenever I use Reason rewired to Reaper in parallel to VSTis. But it frets me that I can't make use of your synths in particular, because they seem to have a wonderful sound.

Quilcom Spectre 1.11 as VSTi in Reaper
AMD Athlon II X2 250 (2 cores @3Ghz)

Spectre loaded, record armed, idle: 5-7% in TaskManager
7 note chord played: 23-30% in TaskManager

(compare it to my example of Reason playing with 13% in TaskManager)


@KG
I like #5
Well, it wasn't so much about Flowstone's performance. I think that it is performing quite well. It's more that I am wondering, why VSTis in general take so much CPU load, while Reason is so much more lightweight. It feels like Propellerhead is doing something right, that all others don't do.

Think about it: Flowstone's dll is an optimized collection of VST 2.3 SDK. On top some instructions on how an when to run certain functions. While the editor is very "sensitive" (read: crashes often), the dll is pretty stable. I think it is as fast as could be (with its special functionality of allowing per-sample-editing). Also, Reaper is a damn good DAW. It's programmers didn't come from nowhere. They were the developers of WinAmp. They only hire explicit audio programmers. Their software is highly optimized. The engine rock-solid and ultra-fast. The VST interface is as good as can be, it even has special modes for instruments/effects that have bugs. So it seems VST itself is the bottleneck, if I can have the same functionality in Reason for a fraction of the CPU load.
I wonder what their trick is, that VST is not using?

EDIT: Another example. When doing the song for Spogg's Flowstone Music thread, I wasn't able to run the whole song just from the VSTis. The cpu load was so high, that I had to create stems after three tracks (3 instruments plus 6 effects, all done with SM/FS, but I doubt it would have been better with non-FS VST). That's really reminding me of the early eighties, where I had like 4 tracks in total.

[Spogg]

Hi tulamide; of course I don't mind you using my stuff for any purposes!

The only thing I can think of as to why Reason uses generally less CPU than VSTi is that Propellerheads have control over every single line of code because it's a closed system. I imagine (I don't know) that the VST protocol must have some overheads to make the interfacing universal. Having said that it's hard to see that any such overheads would amount to such a large impact on CPU usage.

Of course the elephant in the room is your PC spec (so sorry to mention it!). The CPU was released over 6 years ago and the reviews I have just read, made at the time, were not complimentary even then, especially about the cache size.

Christmas is coming and I reckon you deserve to treat yourself a little (like BobF did!).

Cheers

Spogg

[tulamide]

Oh, you're so right! I even still run WinXP! Yes, the cpu is old and was mediocre even when it came out. I'm aware of it. But a new cpu doesn't solve it: It is just giving me more headroom

The difference between Reason/VST stays the same. Btw., I'm surprised how close we are, comparing a top notch actual processor with my 6 year old mediocre one. It might not have that much influence, which is amazing. Compare the graphics from 2008/9 with actual graphics in games. That makes much more of a difference (my GTX460 would do something like 10 fps in Witcher 3 - with your cpu)!

[KG_is_back]

It's more that I am wondering, why VSTis in general take so much CPU load, while Reason is so much more lightweight. It feels like Propellerhead is doing something right, that all others don't do.

Oh, I misunderstood the question. Yes, VST format has some crazy internal routing. After all, its Virtual Studio Technology - from day 1 if was meant to be usable for more than just sound processing. Namely they are planing to add support for video processing as well - it's just not ready yet.

I don't really know the technicalities, but if you build plugin that is specifically meant to work with certain software it will work much more efficiently. Most DAWs have their own native plugin format and VST support is implemented via wrapper of some sort, which adds another stage of processing. However, it shouldn't matter THAT much - the bulk of the processing should be the audio processor part, which I'd assume should work the same, no matter what format the plugin is. Basically I have no satisfying answer to your question.

Speaking of computers, mine broke yesterday. The monitor fell of, speakers sound funny and some F keys are broken. It might take a while until It gets fixed or get a new one

[Spogg]

I do wonder if the Steinberg VST SDK is not very optimised. I don't code so I don't know, but it's possible that if the SDK is involved in compiling that could be the bottleneck maybe.

Whatever.
That's the way it is, so a faster PC is the way forward. Then it doesn't matter I guess.

So... Tell santa

Cheers

Spogg