It seems that Hyperthreading on eats all my CPU

[EnochLight]

Hyperthreading in Reason has always been janky/broken/poorly implemented from the start - I seriously don't ever see this changing any time soon. For those of you who did see performance increases when using it, I'd wager you're the rare exception to the rule.

[dakta]

I suppose the topic of whether hyperthreading is an actual benefit in the context of reason deserves a topic of its own really - without being an audio processing guru (more IT) single core performance improvements haven't been as staggering, recently built a pc and the benchmarks for single core performance wasnt so drastically different from the machine it replaced though multicore/multiple threads it got thrashed so if the software could make benefits from multiple cores or threads it'd be a good way of making use of recent tech

Programmatically it can be a royal pain in the butt and not every task lends itself easily to it. It would be nice if RS could fix the bugs, where the OP is concerned though i think its a case of 'the settings that definitely worked for me quite well now dont work for me at all since an update - should this be addressed?'

answer is yes (not read the manual) - though whether it gets developer attention or not is again another topic completely, I suspect unlikely ha.

[Zac]

Hyperthreading in Reason has always been janky/broken/poorly implemented from the start - I seriously don't ever see this changing any time soon. For those of you who did see performance increases when using it, I'd wager you're the rare exception to the rule.

It really bothers me that so many of us expect so little from Reason Studios. An analogy with an abusive relationship is incorrect as they do me no harm but I have very low expectations of them and yet still haven't fully invested in a new DAW.

I think I'm going to change that this year.

[guitfnky]

Hyperthreading in Reason has always been janky/broken/poorly implemented from the start - I seriously don't ever see this changing any time soon. For those of you who did see performance increases when using it, I'd wager you're the rare exception to the rule.

exactly. I wouldn't at all be surprised if the OP was one of those lucky outliers up until the update, and the update just brings his experience in line with the majority of other users.

is it great? no. is it something they should look at making more consistent? sure. is it a bug? probably not--unless you consider the way it's always worked a bug.

[Heigen5]

Hyperthreading in Reason has always been janky/broken/poorly implemented from the start - I seriously don't ever see this changing any time soon. For those of you who did see performance increases when using it, I'd wager you're the rare exception to the rule.

exactly. I wouldn't at all be surprised if the OP was one of those lucky outliers up until the update, and the update just brings his experience in line with the majority of other users.

is it great? no. is it something they should look at making more consistent? sure. is it a bug? probably not--unless you consider the way it's always worked a bug.

Well if it did increase my CPU by 8 seconds in the benchmark test just one release earlier, so my question is, what's the reason for changing it.
By the way, lots of the people having it on, might have opened shitloads of tickets, because they didn't know why their monster PC's can't even handle 1 Antidote in the rack.
Some users probably got a panic that their computer got broken.

[Heigen5]

And also, the combi2 patch-switching loading times are like 4 seconds more than in the 12.2.2

[stratatonic]

Thought I'd throw this in here, rather than starting a new thread.
I'm completely baffled about how this multi core/hyperthreading/DSP thing works.

When I click on hyper-threading, I have a lower CPU usage, but a higher DSP level in Reason
multi-core higher CPU, but lower DSP (was mostly on 2 bars, flickering on 3)
both on, heavier CPU still, lower DSP

If I just went by Reason"s meter, I'd choose the lower bars, but doing that uses more CPU!
.

Hyper On DSP 4 bars 20% CPU .png (34.75 KiB) Viewed 1405 times

Multi On DSP level 2 .png (39 KiB) Viewed 1405 times

Both On DSP 2 bars 36% CPU.png (40.46 KiB) Viewed 1405 times

[avasopht]

I disagree with this (though admittedly have been unable to duplicate the issue with performance being effectively similar)

if it was working both ways without dropouts before, I suspect

There's no need to suspect anything - it if was working both ways before and the only thing different is the software version - see where I'm going?

CPUs are complex.

That's all that's happening here.

In the old days, you'd give the CPU instructions and it would execute them all in the order they were written.

Then in the mid 90s CPUs became more complex and started pipelining operations.

Now they're a hell of a lot more complex, and the CPUs are optimised based on the codebases the CPU manufacturers target. It used to be Microsoft code, and for many years Microsoft's compilers were most optimised for Intel processors and Intel processors most optimised for Microsoft code.

Hyperthreading makes it even more complex.

CPUs even run the Minix operating system behind the scenes and convert the program's machine code to its own internal CPU instruction set. It does this differently depending on what it anticipates the workload to be.

All the while, the CPU is sharing its limited CPU resources between virtual cores, and when it gets it wrong can make threads stall.

This isn't a case of Propellerheads doing anything inherently wrong, it's just the fact of hyperthreading throwing a spanner of unpredictability into the works. And so, for DSP workloads you may find hyperthreading reduces overall performance.

Your CPU with 8 virtual cores will typically have 4 real cores. What hyperthreading does is do a little bit of misdirection and sleight of hand to behave as if it has twice as many cores, when really it just has 4 cores but 8 sort-of micro cores for lightweight instructions.

Virtual cores suit programs that aren't doing stuff where the real cores are the bottleneck (such as doing lots of SIMD or floating-point arithmetic).

An arbitrary change in code such as putting swapping around the order of a few procedures, or renaming files so that the compiler processes them in a different order can result in a different indirect utilization of CPU resources.

Anyway, for this type of workload, it's often recommended to switch off hyperthreading (but sometimes it's fine ... and might be the case when you've got enough real cores that very little gets distributed to virtual ones).

[challism]

This could also be the problem

CPU Monster.jpg (22.15 KiB) Viewed 1370 times

[ScuzzyEye]

Another data point that's being missed in this thread. The DSP meter doesn't measure CPU usage (directly). It is an indicator on how quickly Reason is finishing it's processing, but it's based on how empty the buffer is getting. When the meter is full, the buffer is empty and audio will drop out. The way the buffer is used, is that Reason renders slightly ahead of what you're hearing. That way if there are momentary bits of the song that take longer to render than they would take to play it can dip into that buffer and not drop out audio. As it uses part of the buffer it lights up a bar on the DSP meter. The more CPU intensive a song is to render the more Reason has to rely on the buffer.

Throwing more CPU time at the rendering process might make Reason depend less on the buffer. So it's very likely higher CPU usage = lower DSP buffer usage.

[Carly(Poohbear)]

I have not read all the threads on this post however

Due to the indexing that R12 is doing you will see one your processes high for about 5 to 10 minutes depending on your setup while it's checking all your refill's etc.

Hyperthreading SHOULD help as when turned on it's using all the cores, when off it's the old x-1. (overall it has not helped me)

Looking at % and hyperthreading confuses most people, e.g. hyperthreading off, if you see a load of 45% etc. you are nearly at a 100% and when you turn it on you may see a load close to 100%, part of this is a maths game and a workload, I did explain it in one of my video's about 10.3 performance.

[drloop]

Back in the days when I worked with High Performance Computers there were workloads that behaved exaclty lika Reason do with Hyper Threading on, specially workloads across many CPUs and with low latency network interconnect.
Solution, turn HT off.

I just turned off HT on my Ryzen 5900x and now it is performing absolutley excellent. Went from 30% on my largest projects down to 10% CPU usage.
HT is not suitable for all workloads, most applications with realtime performance demands such as a DAW will not benifit from HT.