It seems that Hyperthreading on eats all my CPU

[Heigen5]

I just had only 1 Antidote in the rack and played some chords and noticed all my CPU being eaten out. I was like wtf, I have a Intel(R) Core(TM) i9-10900K 10. Gen. 10 Cores CPU @ 3.70GHz 3.70 GHz - Turbo 5,3Ghz.
So I went and turned the hyperthreading off and my performance got normal again. And it seems like this behavior happened due the latest update (12.2.3) because I had it always on before.

Anyone else noticed this?

[riemac]

I have the same prozessor and the same problem. First time I had to switch of hyperthreading after installing 12.2.3. I opened a ticket and hope this will be solved in a future update.
What is strange, is that the last virtual core 20 is used 100% on my system with hyperthreading on, because of that my fan is working hard. All other cores are fine with a low cpu usage.

[Heigen5]

I have the same prozessor and the same problem. First time I had to switch of hyperthreading after installing 12.2.3. I opened a ticket and hope this will be solved in a future update.
What is strange, is that the last virtual core 20 is used 100% on my system with hyperthreading on, because of that my fan is working hard. All other cores are fine with a low cpu usage.

Ok, you opened a ticket, great, hope the Reason Studios find a cure for this problem we have.

[Heigen5]

I opened a ticket too just in case.

[doze]

Not seeing the problem here. but on i9-11900K, so perhaps processor specific.

[Heigen5]

Not seeing the problem here. but on i9-11900K, so perhaps processor specific.

Ok. How is your combi patch switching speed as I just noticed that switching combi patches is really slow for me which also wasn't so a release earlier?

[Mataya]

I got 10850 i9 and i7 8750 and have to play reason with hyper off on both pc's.

M

[Heigen5]

I got 10850 i9 and i7 8750 and have to play reason with hyper off on both pc's.

M

Ok wow, seems like RS has hard time to make a bugfree Reason in the nowdays.
I'll go back to version 12.2.2 as at least it didn't overall have as many bugs on my end.

[guitfnky]

not to be that guy, but I guess I'm gonna be that guy...RTFM.

it's been this way since they introduced the option.

from the manual:

About hyper-threading audio rendering
Hyper-threading audio rendering could improve the performance even further. Note that this depends on your computer’s CPU and other hardware, so there is no guarantee the performance will improve. If you are experiencing performance problems, try activating or deactivating this to see if the performance improves.

[Heigen5]

not to be that guy, but I guess I'm gonna be that guy...RTFM.

it's been this way since they introduced the option.

from the manual:

About hyper-threading audio rendering
Hyper-threading audio rendering could improve the performance even further. Note that this depends on your computer’s CPU and other hardware, so there is no guarantee the performance will improve. If you are experiencing performance problems, try activating or deactivating this to see if the performance improves.

Not to be that guy but Hyperthreading did improve my CPU in the Reason 12.2.2

[guitfnky]

not to be that guy, but I guess I'm gonna be that guy...RTFM.

it's been this way since they introduced the option.

from the manual:

Not to be that guy but Hyperthreading did improve my CPU in the Reason 12.2.2

so? they changed the code. change your setting.

[Heigen5]

Not to be that guy but Hyperthreading did improve my CPU in the Reason 12.2.2

so? they changed the code. change your setting.

I rather would make the Hyperthreading working again, but I guess that is a weird thing from my part.

[orthodox]

Make Hyperthreading Great Again!

[guitfnky]

so? they changed the code. change your setting.

I rather would make the Hyperthreading working again, but I guess that is a weird thing from my part.

I mean it says right there in the manual to use whichever gives the best performance. it doesn’t necessarily mean you had better performance in the prior version with it on than you do now with it off. did you run benchmarks? I doubt it.

[Heigen5]

I rather would make the Hyperthreading working again, but I guess that is a weird thing from my part.

I mean it says right there in the manual to use whichever gives the best performance. it doesn’t necessarily mean you had better performance in the prior version with it on than you do now with it off. did you run benchmarks? I doubt it.

I benchmarked in the last autumn and hyperthreading increased my CPU for 8 seconds or so.

[guitfnky]

I mean it says right there in the manual to use whichever gives the best performance. it doesn’t necessarily mean you had better performance in the prior version with it on than you do now with it off. did you run benchmarks? I doubt it.

I benchmarked in the last autumn and hyperthreading increased my CPU for 8 seconds or so.

the point has successfully traversed the airspace over your head.

[Heigen5]

I benchmarked in the last autumn and hyperthreading increased my CPU for 8 seconds or so.

the point has successfully traversed the airspace over your head.

What? I think my point didn't get in your head though.

[huggermugger]

Hyperthreading is no guarantee of improved performance, and can in fact compromise performance because of the way it works.

[Heigen5]

Like I said, it did increase in the Reason 12.2.2.
You can now skip this statement again.

[guitfnky]

the point has successfully traversed the airspace over your head.

What? I think my point didn't get in your head though.

right.

[dakta]

Let's be fair, this isn't a case of preference - there clearly is a problem i.e because even if hyperthreading doesn't provide a performance benefit in a particular use case, I think it's reasonable to say finding all cores saturated under such a small practical workload is not normal or expected behaviour.

Hyper-threading audio rendering could improve the performance even further. Note that this depends on your computer’s CPU and other hardware, so there is no guarantee the performance will improve.

The way i read that is 'you may see a performance benefit but don't expect much, and it depends what you have'. It doesn't suggest to me 'this may improve your performance, but if it doesn't, it will consume all processing power from all available cores'. I think we are making a fairly dramatic interpretation of this text.

If you don't think this is a bug, and that simply using a setting which does ;work; but provides lesser performance than before the 'bug' appeared is acceptable, that's fine but the OP doesn't agree, and that's also fine because the user has said they have used this setting with success previously.

There is something to fix, there is a workaround that can be used so thankfully the OP can still get some work done with not a big impact but that doesn't mean the jobs done at all. Don't think it's un-reasonable (ha - geddit?) to acknowledge there's a bit of a sizeable gap between a setting not being guaranteed to improve performance and nuking a systems resources (especially when it didn't a few versions ago).

[guitfnky]

Let's be fair, this isn't a case of preference - there clearly is a problem i.e because even if hyperthreading doesn't provide a performance benefit in a particular use case, I think it's reasonable to say finding all cores saturated under such a small practical workload is not normal or expected behaviour.

Hyper-threading audio rendering could improve the performance even further. Note that this depends on your computer’s CPU and other hardware, so there is no guarantee the performance will improve.

The way i read that is 'you may see a performance benefit but don't expect much, and it depends what you have'. It doesn't suggest to me 'this may improve your performance, but if it doesn't, it will consume all processing power from all available cores'. I think we are making a fairly dramatic interpretation of this text.

If you don't think this is a bug, and that simply using a setting which does ;work; but provides lesser performance than before the 'bug' appeared is acceptable, that's fine but the OP doesn't agree, and that's also fine because the user has said they have used this setting with success previously.

There is something to fix, there is a workaround that can be used so thankfully the OP can still get some work done with not a big impact but that doesn't mean the jobs done at all. Don't think it's un-reasonable (ha - geddit?) to acknowledge there's a bit of a sizeable gap between a setting not being guaranteed to improve performance and nuking a systems resources (especially when it didn't a few versions ago).

I don’t agree with this. I’ve used Reason on a Mac and four PCs—all but one quite powerful for their times (top line iMac, i7s, and now a 3900x). in every single case, one setting worked fine, and the other caused dropouts regardless of how light a project I had.

that’s no different than what’s been described here. the only difference seems to be he needs to switch the option the other way. if it was working both ways without dropouts before, I suspect performance was still actually better with the setting that works for him now—he was likely just lucky enough to not realize it. fine to open a ticket with them to research, but to complain about it being a bug when it works exactly as described in the manual is silly—especially when there are still plenty of actual bugs in the current version.

[Heigen5]

when it works exactly as described in the manual is silly

The only thing that is silly is that hypertheading code got bad. It's like a motorbike had a nitro to speed it up, but was taken away for a no reason.

[dakta]

Let's be fair, this isn't a case of preference - there clearly is a problem i.e because even if hyperthreading doesn't provide a performance benefit in a particular use case, I think it's reasonable to say finding all cores saturated under such a small practical workload is not normal or expected behaviour.



The way i read that is 'you may see a performance benefit but don't expect much, and it depends what you have'. It doesn't suggest to me 'this may improve your performance, but if it doesn't, it will consume all processing power from all available cores'. I think we are making a fairly dramatic interpretation of this text.

If you don't think this is a bug, and that simply using a setting which does ;work; but provides lesser performance than before the 'bug' appeared is acceptable, that's fine but the OP doesn't agree, and that's also fine because the user has said they have used this setting with success previously.

There is something to fix, there is a workaround that can be used so thankfully the OP can still get some work done with not a big impact but that doesn't mean the jobs done at all. Don't think it's un-reasonable (ha - geddit?) to acknowledge there's a bit of a sizeable gap between a setting not being guaranteed to improve performance and nuking a systems resources (especially when it didn't a few versions ago).

I don’t agree with this. I’ve used Reason on a Mac and four PCs—all but one quite powerful for their times (top line iMac, i7s, and now a 3900x). in every single case, one setting worked fine, and the other caused dropouts regardless of how light a project I had.

that’s no different than what’s been described here. the only difference seems to be he needs to switch the option the other way. if it was working both ways without dropouts before, I suspect performance was still actually better with the setting that works for him now—he was likely just lucky enough to not realize it. fine to open a ticket with them to research, but to complain about it being a bug when it works exactly as described in the manual is silly—especially when there are still plenty of actual bugs in the current version.

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?

fine to open a ticket with them to research

That is correct, it absolutely is fine

but to complain about it being a bug when it works exactly as described in the manual is silly

See, I really don't see how this is an exact match with what the manual says.

Hyper-threading audio rendering could improve the performance even further. Note that this depends on your computer’s CPU and other hardware, so there is no guarantee the performance will improve.

It says performance could be improved. It also says that it is not guarenteed. I don't see anything saying all resources will be suddenly consumed when conditions are not ideal. What it does say is:

f you are experiencing performance problems, try activating or deactivating this to see if the performance improves.

which does suggest performance may decrease, but it doesn't suggest in any exacting terms whatsoever that total core or processing consumption is expected. Also note the phrasing 'see if performance improves' - if the wrong setting is known to affect performance this much to the degree it gets a mention in the manual (which it doesn't seem to anyway) then why would we put the setting back to 'see' if it improves? it should.

So whilst I'd say its fair to fiddle with the settings to find your own personal optimal, I'd argue that a vague 'if you experience performance problems try activating or de-activating' said feature is more of a catch all than a definition of reasonably expected behaviour.

It's not like this is an unknown - the OP knows what settings worked (from their own experience) and they know how well these settings worked (from their own experience) and wants (their own experience) back.

[riemac]

The main problem is, that the CPU usage of Reason 12 is much higher on my system (Intel i9-10900K and Intel UHD Grafics 630) compared to Reason 11.
I notice in Reason 12 that the last virtual core uses much more CPU in comparison to Reason 11.
My guess is, that this has to do with the new grafic randering, because when I close Reason 12 from view and let the song play in the background, the CPU usage of the last CPU core drops to almost zero!
I've attached some screenshots of the Task-Manager showing the CPU usage of Reason 11 and 12 playing the same song.