Most CPU efficient host?

[SuperFly76]

I was also wondering about just a wrapper to host DIVA to her fullest possible on my hardware without a lot of overhead, something I could load and just play without the host sucking up any juice. Anyone have any recommendations regarding that?

Herman Seib's SaviHost will do just that. I use it all the time when I just want to noodle around with a synth.

[Mutant]

BTW It may be a good idea to use Process Explorer for measurements instead of the standard windows Task Manager.

But of course it is still best to do the "active plugin number before it starts crackling" test because it gives us the most important info.

[aciddose]

when you get this impossible result in reaper, set this up:

1) stop reaper and studio1 from running on any but one core. you can do this by right-click in task manager
2) pass white noise through the complete audio chain (asio in to asio out, through all plugins)
3) make sure all guis are closed

if you still get the same result, it can only be something to do with alignment. there is nothing the host could do that would magically make the plugin run 10x faster.

also, observe the logic applied in this video:

[tony tony chopper]

if you still get the same result, it can only be something to do with alignment

You keep talking about alignment, but alignment of what, the in & out buffers?

A serious plugin will obviously have several, aligned, temporary buffers of its own, and won't process that much on the in/out buffers themselves, so it'd have a neglectable impact, except for very light plugins (EQs, etc) that may really process on them directly. But I still wouldn't count on it having such a drastic impact, it's obvious that hibidy relied on Reaper's own meter. I was gonna say earlier in this thread that part of Reaper's fame for efficiency was linked to its meter, but it sounded too insulting, but it turns out it's true.
(what Reaper has that's unique however is "FX render-ahead" (I believe it had another name?), which is nice but also has drawbacks that I don't think many people understand, and it matters when comparing things).

It's really delicate to test this kind of thing. Take for ex the # of threads involved. A host could think "there are 4 cores on this computer, I will have 4 threads running, because I will never have more than 4 threads processed at once". With well-written plugins it's fine, and will perform better than a host that created more threads. Now if in the chain you've got plugins that constantly do synchronization/often wait, the plugin is gonna block threads frequencly, and the host with more threads will perform better, because it will have "something to do" to keep all cores busy while a thread is in a waiting state.
It's much easier to multithread something that you wrote entirely yourself, which is why I now also multithread my synths, it's efficient because I know what's going on inside. With third-party plugins you never know.


Side note, alignment of the processing length is more important, not really for CPU usage, but related to bugs. When I added an option to align processing lengths to 8 frames, I was expecting slightly lower CPU usage, because plugins that use SSE and/or unrolling would then never have remainders to process. In practice, the improvement was hardly measurable. However it appeared that the option made some plugin work without crackling. Turns out that some shitty programmers are processing aligned lengths, regardless of the length passed, most likely because it's easier & "it always works in Cubase".

[aciddose]

yes i know all of that of course. i'm just still keeping on the side of reaper users not being totally idiotic.

right? they have at least the level of intelligence of a 4-year-old, so let's not assume any worse just yet.

(when you say the sky is green, are you looking at the sky or the ground?)

what could it possibly be influenced from the host side?

only thing i can think of is alignment or buffer lengths like i mentioned. it could also be length of time spent in host callbacks... only a few things and all of which a plugin should never do and never be influenced by.

so it's in that respect 100% a straw-man. using a buggy plugin to claim one host can produce better results than the other.

really though, what could it be? anything i've missed?

(perhaps we forgot to press the turbo button?)

[tony tony chopper]

only thing i can think of is alignment or buffer lengths like i mentioned. it could also be length of time spent in host callbacks...

among the lots of little things that can make a host lost a % here & there (so, that matter when using a lot of light plugins, not a couple of CPU hogs):

-interlaced vs splitted buffers. For ex, FL & my plugins use interlaced stereo, VST is splitted. So there's conversion going on (pretty neglectable these days)

-having to secure FPU & SSE states that plugins may change (neglectable too)

-other compatibility stuff/babysitting that some plugins need (could be a viible user setting in one host, and autodetected from a list in another host)

-tick-based processing. That is, either the host processes plugins in 1 pass for the entire ASIO buffer, or does this in several, tick-aligned passes (some hosts, like FL)

-priority (also multimedia priority) of the processing threads, because of priority inversion I believe it's not as important as it sounds, & also the method used to make those threads wait

-threaded vs bridged, huge difference here. But I assume that the user knows when he's using a bridge.

-ASIO buffer handling, more efficient when using triple-buffering (you will get crackling less early, really depends on how late the bufferswitch is triggered), but then the user has to know that it increases latency

& I'd just ignore the "host X processes 10x more plugins", the differences are probably very small, in the very worst case (a single-threaded vs multithreaded host, on a quad) around 3x-4x using a benchmark.

[Mutant]

Just FYI:

When REAPER says 2% it must really mean 2% because here on my 2 core PC it begins to crackle when the load passes about 90%.

Thats on 20ms latency setting on E-MU 1212M and no record armed on any track (anticipative fx processing enabled).

[Mutant]

Yeah i just checked it again with about 100 tracks of Synth1 playing 8 voices each and the audio was smooth while the GUI had serious problems updating in real time (maybe about 2 to 5 frames per second) at about 88% to 92%.

[aciddose]

that's fine but we're concerned about the claim that one plugin runs 10x faster in reaper. that just doesn't make much sense.

two good points:

- bridging
- driver configuration & process priority

the other stuff isn't really relevant in this particular test case. i know flstudio does that interlacing stuff... actually does it still do only "tick based" processing? i thought fl's vst wrapper supports breaking the audio blocks into smaller pieces only when events are happening? in which case in this particular test it should only process 100% chunk sizes?

(although he wasn't testing fl here, it was studio1 vs. reaper, right?)

[Mutant]

that's fine but we're concerned about the claim that one plugin runs 10x faster in reaper. that just doesn't make much sense.

Right.

I guess it just runs normally like it should in REAPER and that other host (was it Studio One ?) is bugged or badly designed and runs it 10x slower.

It would be physically impossible to make a plugin run 10x faster than on the other host on the same CPU if the other host was working properly.

[aciddose]

actually it isn't impossible. i could make a plugin that always takes 33% of the cpu time on any cpu or core in any host Just meter the cpu time from inside the plugin and hog it until you take as much as you want.

you could also check which host you're running in by asking the host (part of the vst spec) and then if you're in cubase, run normally. in reaper go into a loop ten thousand times calculating random numbers and throw the result out.

or you could bugger things up even worse. if you're running in reaper, spit out a lot of denormals in place of zeros. your plugin would still process at normal speed but the host and any plugins afterward would suddenly run way worse

all those are crazy though. i can't think - even taking into account things i mentioned and tony mentioned - of anything that would create more than maybe a 2x difference that the host was totally in control of.

when we're talking about processing with blocksize of 1 sample in one host and 256 samples in the other, that isn't "in the same conditions" anymore. that's a totally bogus test. although fl for example uses smaller block sizes most of the time it makes absolutely no difference! 1 vs. 256 would be a totally biased and extreme set-up situation.

[tony tony chopper]

You're debating on what could be the cause of something that most likely isn't any true & is only a conclusion from a shady source (I know he will find it insulting & get angry again, but let's face it, it's the truth)

If I was timing an event and the result came up negative, I know I'd question my timing way before investigating how I achieved time travel.


Also as I wrote before, energy-saving settings are very important & should be turned off. I don't think that an app can switch them off easily, or that any sequencer does, though (it'd be wrong to do so anyway).

To add to the list of little things, there's also a part of luck. For ex, my previous quad core had cache shared by pairs of cores. Depending on which core the threads timeslices ended up, CPU usage was quite different. Also there's hyperthreading, my system has 8 virtual cores, but only 4 of them are real ones, the rest is hyperthreading, which isn't really efficient, but the task scheduler seems clever enough to use the real cores first.

[deleted]

DELETED

[aciddose]

you're 100% correct. just, like i said i would "assume" he's already considered whether his measurement is bogus. we can assume it's bogus all we want and ignore him if we want. (i'm sure we both do already.)

the next step after you confirm your measurement though is to create a theory of how you think it could be true. you can't just 'jump to conclusions" like most people seem to have done and assume reaper is 10x faster.

perhaps it is, but why? i could like i said write a plugin easily that runs 10x slower in only reaper and so would they also jump to the conclusion that with my plugin reaper is at fault and 10x slower?

asking questions like these expose the kind of bias we assume we're seeing here.

i'm only trying to offer reasonable theories. you say they're pointless, and i agree. i think we also both agree they could produce maybe 2x differences. can hibidy produce a theory that can account for his 10x difference? magic? pixie dust?

[Kriminal]

he wasn't testing fl here, it was studio1 vs. reaper, right?

doesnt matter, even if it was the uss enterprise in warp mode vs reaper, reaper would win....