Hydlides rant about performance

This forum is for discussing Reason. Questions, answers, ideas, and opinions... all apply.
User avatar
Loque
Moderator
Posts: 11175
Joined: 28 Dec 2015

03 Jul 2018

I guess a few of you have seen Hydlides rant abour Reasons performance, especially since he bought a 14 core CPU.


This video made me think about how PH probably has implemented their multi core rendering. And the fact, that all CPUs and threads are working as soon as there is something going on, i guess they have reveresed the multi-core rendering than it is usually implemented.

Let me explain: In normal cases you have jobs to be done. Each jobs has its context, that means things need to be done before and after it, where some jobs can run independently. A simple example is (1)"audio->fx->fx" for a serial sequence part, and (2)"audio1", (3)"audio2" as independent parallel jobs. Jobs (1) to (3) can be send to different cores/threads to be rendered, as long as they are not related, which would result in 3 cores working at the same time.

But, the fact that all cores and threads are running at the same time, the jobs are not send to the cores, but in reverse the cores and threads are activated and poll a centralized job queue. Maybe there are several queues for individual parallelism and the cores and threads check them each.

So where is the difference between sending to cores and let the cores poll? Here are the few things that came in my mind
* power consumption
* cache invalidation
* prediction invalidation
* blocking of threads/cores while accessing the queues
* the cores/threads get a job if they are free and do not have to be idle as it would be in bad scheduling of sending jobs

What does this type of implementation indicate?
* it was probably the easiest and quickest way to implement it
* probably the better core-self-balancing instead of complicated extra balancer overhead
* bad job identification and scheduling
* Following points may also hit on job sending systems:
** architecture dependencies
** hard coupling, bad cohesion
** lot of synchronization may be required
** global buffers

Conclusion:
I am not sure, that the things that Hydlide is seeing are a real issue and can be used for comparison or performance indication. If it is implemented in such i way i speculate, it is the through-put what counts in the end. But polling is never a good way of implementation, because it keeps the system busy where it does not need to be. A more smarter balancing (and some cores can be faster than others), more isolated jobs, less coupling, less locking, better architecture will come automatically, if you implement more isolated jobs. A long way to go maybe...

All this is my opinion. Nothing official.
Reason12, Win10

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

03 Jul 2018

Why would there be any polling when you have a steady pulse of sample batches coming in? All of this is pulled out of VERY thin air.

You're right though that threading is a complicated topic that not even all programmers have a firm grip on. I once made a video about this in the forum of an open source game engine that I co-wrote as there were many beginner programmers who had.... let's say issues with the topic :)


User avatar
EnochLight
Moderator
Posts: 8405
Joined: 17 Jan 2015
Location: Imladris

03 Jul 2018

TL;DR. Or watch.

Props have already said they’re working on performance, and will release an update to address it. Did he really need to dedicate a whole video to this? I guess his wife is doing OK (which is nice to hear)?
Win 10 | Ableton Live 11 Suite |  Reason 12 | i7 3770k @ 3.5 Ghz | 16 GB RAM | RME Babyface Pro | Akai MPC Live 2 & Akai Force | Roland System 8, MX1, TB3 | Dreadbox Typhon | Korg Minilogue XD

User avatar
Oquasec
Posts: 2849
Joined: 05 Mar 2017

03 Jul 2018

Does Reason 9 & 10 act up for yall if you enable the options reason 5 didn't have?
Producer/Programmer.
Reason, FLS and Cubase NFR user.

User avatar
guitfnky
Posts: 4408
Joined: 19 Jan 2015

03 Jul 2018

his videos are great, when he’s teaching how to use devices. his videos are terrible when he’s got a bone to pick. really wish he’d just stick to the former.
I write good music for good people

https://slowrobot.bandcamp.com/

antic604

03 Jul 2018

From my own experience - on a measly i7-6650U in Surface Pro 4 - disabling hyperthreading also helps, because for this 2-core / 4-thread processor when multi-threading is ON, Reason only uses 3 threads and 4th is used in 10-20%, probably only to manage job scheduling. So it's a different type of problem compared to Hydelide describes, but the end result is the same - the option needs to be OFF.

User avatar
fotizimo
Posts: 285
Joined: 15 Jan 2016
Location: Canada
Contact:

03 Jul 2018

antic604 wrote:
03 Jul 2018
From my own experience - on a measly i7-6650U in Surface Pro 4 - disabling hyperthreading also helps, because for this 2-core / 4-thread processor when multi-threading is ON, Reason only uses 3 threads and 4th is used in 10-20%, probably only to manage job scheduling. So it's a different type of problem compared to Hydelide describes, but the end result is the same - the option needs to be OFF.
Thank you for writing this. As the owner of a SP4 with the same CPU set, I couldn't determine if the setting should be off or on. I do not have the tool set to measure what the differences do on the SP4, but through my trials, didn't really see any changes to the CPU performance, or DSPs for a variety of tests. I had kept it on as I wasn't sure if it accomplished anything or not.

As for Hydelide's rant, I think we need to keep any/all pressure on PH to fix performance with Reason. They have chosen new instruments time and time again, and left us all with the "performance will be fixed soon" answer, and I am growing tired of waiting. No other DAW performs as poorly on my SP4 as Reason does, and it is more than time for PH to step of and optimize their product.

PH, the time is now to address your loyal customer-bases performance requests.
Fotizimo @ Instagram
:reason: on Surface Pro 4
Nektar Impact 25
Novation Launchkey Mini
Arturia SparkLE Spark Codec for Reason

User avatar
O1B
Posts: 2037
Joined: 26 Jan 2015

03 Jul 2018

Hydlide is on to something.
I hope our sensitivities about Reason don’t inhibit us from constructive critiquing.

I can’t PC - since I MPE and iOS - but, it’s clear to me that Reason runs better on a PC than a Mac. Since Reason 5.

I do hope they solve this issue. It sucks. No sugar coating.
I’m afraid to load the wrong RE (kH One) and have to ‘constantly close’ the files to clear the buffer.

Aside:
“I guess his wi-“
NOT cool bringing up his wife cause we’re upset about his critique, Enochlight.

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

03 Jul 2018

fotizimo wrote:
03 Jul 2018
They have chosen new instruments time and time again, and left us all with the "performance will be fixed soon" answer, and I am growing tired of waiting.
Not correct. They never said anything remotely like "Yeah, Reason is slow and we are aware of that". Simply because it's not true. Their instruments run beautifully with large instance counts and low DSP usage and they are instrument creators since ever, what do you expect?

What they did was say that specific issues are being looked into, like for example the recent performance drop on OSX. Or others like the issues with UAD plugins - which simply stem from the fact that Reason runs at 64 samples internally and the UAD doesn't like that. Please reference what you mean if you think that they did in fact say that Reason needs "performance fixes".

jimmyklane
Posts: 740
Joined: 16 Apr 2018

03 Jul 2018

If kept within it’s designed parameters....In other words, all stock devices, processors, and effects, then I’d say that Reason outperforms every single DAW on the market. It’s when you begin to expand the Reason “universe” with REs and VSTs and even too many external MIDI devices that Reason starts to fall apart.

The shame is, PH gave us the expectations that we’d have for any other DAW, and it cannot keep up. I’m running several networked computers and using almost solely external hardware synths, samplers, processors, and effects so my VERY old computer (an i7 2600k water cooled and overclocked to 4.3GHz) can very easily keep up with 24-48 audio tracks..... all of that said, I’m pretty sure that I’m using Reason the same way I could use Cubase in an Atari ST along with a Tascam X48....which I know is not the norm.

Currently I’m working on a song that uses external synths and samplers, but all of the effects, busses, and master bus are plugins and at 128 samples I’m barely using 1/4 of the DSP meter. I have no idea what people are using to cause something like a 14-core CPU to have trouble with running Reason....it seems like once I put in the fastest RAM my computer could take and bought all SSDs for OS, Audio, and storage that my performance leveled off.

I can very easily record 24 tracks at 88.2kHz into Reason all at once and once inside of Reason use whatever effects and processing that I want to. Maybe I’m just lucky?
DAW: Reason 12

SAMPLERS: Akai MPC 2000, E-mu SP1200, E-Mu e5000Ultra, Ensoniq EPS 16+, Akai S950, Maschine

SYNTHS: Mostly classic Polysynths and more modern Monosynths. All are mostly food for my samplers!

www.soundcloud.com/jimmyklane

User avatar
EnochLight
Moderator
Posts: 8405
Joined: 17 Jan 2015
Location: Imladris

03 Jul 2018

normen wrote:
03 Jul 2018
fotizimo wrote:
03 Jul 2018
They have chosen new instruments time and time again, and left us all with the "performance will be fixed soon" answer, and I am growing tired of waiting.
Not correct. They never said anything remotely like "Yeah, Reason is slow and we are aware of that". Simply because it's not true. Their instruments run beautifully with large instance counts and low DSP usage and they are instrument creators since ever, what do you expect?

What they did was say that specific issues are being looked into, like for example the recent performance drop on OSX. Or others like the issues with UAD plugins - which simply stem from the fact that Reason runs at 64 samples internally and the UAD doesn't like that. Please reference what you mean if you think that they did in fact say that Reason needs "performance fixes".
True, I suppose it's specifically VST performance in Reason that was going to be addressed, at least that's what I got out of Mattias' blog post:

https://www.propellerheads.se/blog/reason-101-is-here
“So, what about performance?” I hear you ask. We are aware of some performance issues with VSTs, and trust me, we’re working hard to adress them. Good news is it’s going really well! But it’s a complex project that requires lots of time for testing. I can’t give you a date at the moment, but this performance optimization will be available as a free update for all Reason 10 owners later this year.
O1B wrote:
03 Jul 2018
Aside:
“I guess his wi-“
NOT cool bringing up his wife cause we’re upset about his critique, Enochlight.
Perhaps, but if he's going to make a public YT video post about it for everyone to "share" in, I just assumed his private life was on display. Also, I'm not upset about his critique; I'm actually in agreement that (VST) performance needs to be improved! I just don't know how much more this dead horse needs to be kicked...

Fun fact: Hydlide doesn't care about the forum at Reasontalk, nor the people/community here. His own words, taken from one of his videos, BTW.
Win 10 | Ableton Live 11 Suite |  Reason 12 | i7 3770k @ 3.5 Ghz | 16 GB RAM | RME Babyface Pro | Akai MPC Live 2 & Akai Force | Roland System 8, MX1, TB3 | Dreadbox Typhon | Korg Minilogue XD

User avatar
O1B
Posts: 2037
Joined: 26 Jan 2015

03 Jul 2018

+10 to the First Comment
+20 to the Second Comment.... 88.2kHz.... nice one...
you must have done some reading, Sir.
jimmyklane wrote:
03 Jul 2018
If kept within it’s designed parameters....In other words, all stock devices, processors, and effects, then I’d say that Reason outperforms every single DAW on the market. It’s when you begin to expand the Reason “universe” with REs and VSTs and even too many external MIDI devices that Reason starts to fall apart.

I can very easily record 24 tracks at 88.2kHz into Reason all at once and once inside of Reason use whatever effects and processing that I want to. Maybe I’m just lucky?

tibah
Posts: 903
Joined: 16 Jan 2015

03 Jul 2018

Apologize for my ignorance here but:
Threading within a multi-core setup, as far as I know, can only work by track/channel. You can't split one instrument over several cores, right? Unless, you are u-he and actually build your instruments to have multi-core support, like Diva, RePro and Bazille (btw, Reason is the only DAW to have issues enabling this feature on said synths). But for all DAWs this means that multi-core works specifically great because you will have several tracks/instruments that are then spread over your available cores.

E.g.
Track 1 = Synth 1, EQ 1, Comp 1, Delay 1 = run on Core 1
Track 2 = Sampler 1, EQ 2, Comp 2, Reverb 1 = Core 2
etc.

So, what is Hydlide on about here, using just one instance of Expanse?

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

03 Jul 2018

tibah wrote:
03 Jul 2018
Apologize for my ignorance here but:
Threading within a multi-core setup, as far as I know, can only work by track/channel. You can't split one instrument over several cores, right? Unless, you are u-he and actually build your instruments to have multi-core support, like Diva, RePro and Bazille (btw, Reason is the only DAW to have issues enabling this feature on said synths). But for all DAWs this means that multi-core works specifically great because you will have several tracks/instruments that are then spread over your available cores.

E.g.
Track 1 = Synth 1, EQ 1, Comp 1, Delay 1 = run on Core 1
Track 2 = Sampler 1, EQ 2, Comp 2, Reverb 1 = Core 2
etc.

So, what is Hydlide on about here, using just one instance of Expanse?
Yep exactly, the plugin decides how many cores it uses and for many things it doesn't make sense to use multiple cores. The DAW can only split up parallel routings, i.e. basically separate mix channels. The DAW can't magically make a single plugins use multiple cores, if it could then the operating system would already do that for the whole system, right? ;)

jlgrimes
Posts: 661
Joined: 06 Jun 2017

03 Jul 2018

Loque wrote:
03 Jul 2018
I guess a few of you have seen Hydlides rant abour Reasons performance, especially since he bought a 14 core CPU.


This video made me think about how PH probably has implemented their multi core rendering. And the fact, that all CPUs and threads are working as soon as there is something going on, i guess they have reveresed the multi-core rendering than it is usually implemented.

Let me explain: In normal cases you have jobs to be done. Each jobs has its context, that means things need to be done before and after it, where some jobs can run independently. A simple example is (1)"audio->fx->fx" for a serial sequence part, and (2)"audio1", (3)"audio2" as independent parallel jobs. Jobs (1) to (3) can be send to different cores/threads to be rendered, as long as they are not related, which would result in 3 cores working at the same time.

But, the fact that all cores and threads are running at the same time, the jobs are not send to the cores, but in reverse the cores and threads are activated and poll a centralized job queue. Maybe there are several queues for individual parallelism and the cores and threads check them each.

So where is the difference between sending to cores and let the cores poll? Here are the few things that came in my mind
* power consumption
* cache invalidation
* prediction invalidation
* blocking of threads/cores while accessing the queues
* the cores/threads get a job if they are free and do not have to be idle as it would be in bad scheduling of sending jobs

What does this type of implementation indicate?
* it was probably the easiest and quickest way to implement it
* probably the better core-self-balancing instead of complicated extra balancer overhead
* bad job identification and scheduling
* Following points may also hit on job sending systems:
** architecture dependencies
** hard coupling, bad cohesion
** lot of synchronization may be required
** global buffers

Conclusion:
I am not sure, that the things that Hydlide is seeing are a real issue and can be used for comparison or performance indication. If it is implemented in such i way i speculate, it is the through-put what counts in the end. But polling is never a good way of implementation, because it keeps the system busy where it does not need to be. A more smarter balancing (and some cores can be faster than others), more isolated jobs, less coupling, less locking, better architecture will come automatically, if you implement more isolated jobs. A long way to go maybe...

All this is my opinion. Nothing official.
I hope they at least put a freeze in for 10.5.

Reason's performance actually wouldn't be too bad if they had freeze.

User avatar
O1B
Posts: 2037
Joined: 26 Jan 2015

03 Jul 2018

See below....

“Although multiple processors are theoretically faster than a single core, writing software that takes advantage of many processors–a task called parallel programming–is extremely difficult.”

... from 2006.

But come on! 2018? Absolutely NO Excuse. Hire that guy, Props!!
tibah wrote:
03 Jul 2018
Apologize for my ignorance here but:
Threading within a multi-core setup, as far as I know, can only work by track/channel. You can't split one instrument over several cores, right? Unless, you are u-he and actually build your instruments to have multi-core support, like Diva, RePro and Bazille (btw, Reason is the only DAW to have issues enabling this feature on said synths). But for all DAWs this means that multi-core works specifically great because you will have several tracks/instruments that are then spread over your available cores.

E.g.
Track 1 = Synth 1, EQ 1, Comp 1, Delay 1 = run on Core 1
Track 2 = Sampler 1, EQ 2, Comp 2, Reverb 1 = Core 2
etc.

So, what is Hydlide on about here, using just one instance of Expanse?

antic604

03 Jul 2018

fotizimo wrote:
03 Jul 2018
Thank you for writing this. As the owner of a SP4 with the same CPU set, I couldn't determine if the setting should be off or on. I do not have the tool set to measure what the differences do on the SP4, but through my trials, didn't really see any changes to the CPU performance, or DSPs for a variety of tests. I had kept it on as I wasn't sure if it accomplished anything or not.
For me the difference was clear when I saw the 4th thread is barely used, when Hyperthreading is ON.

Here's the same project at its peak DSP utilisation with Hyperthreading ON and OFF respectively - the difference is quite substantial: 82% vs. 68% (even though at the moment of capture the former shows 3 DSP bars vs. 4 DSP bars for the latte :)):

Image

Image

In the task bar on the right you can see 4 vertical bars (representing utilisation of threads / cores: blue is 3rd party software, white is Windows) and a pie chart (representing RAM usage) - this is a free XMeters tool to monitor your system's utilisation (https://entropy6.com/xmeters/).

In the picture with Hyperthreading ON you can see that only 3 out of 4 bars are filled in, which means one thread running at 1.5GHz is left idle, which explains the observed difference in performance.

ahuimanu
Posts: 17
Joined: 24 Feb 2016

03 Jul 2018

I had similar problems that I described here - viewtopic.php?f=12&t=7504828

I contacted Propellerheads support and I was kinda told this:


As a result, no reason for months. I got a processor a few steps higher than his in the video (conclusion, a waste of money, and I'll never buy that much processor again) and had nothing but trouble with reason.

My conclusion is that props may have lost their way as they became distracted with mobile, social, and other marginal market-grabbing trends. Hell, even VST is arguably both a distraction and trend-following.

They kept me in their ecosystem with REs and now I feel trapped.

Anyhoo, I can relate to what hydlide is saying from experience.

User avatar
bsp
Posts: 214
Joined: 18 Jan 2015

03 Jul 2018

ahuimanu wrote:
03 Jul 2018
Anyhoo, I can relate to what hydlide is saying from experience.
I'm on an 18 core i9 and I second that emotion.

This video is certainly not a technical breakdown of Reason's limitations (I tried to explain it to you when I got my new many-core PC earlier this year but that techno-mumbo-jumbo was silently ignored, probably b/c few people had access to such a machine themselves).

All I can offer hydlite as a consolation is a sneak preview of my work-in-progress VST host which is designed specifically for these kind of CPUs. That should put a smile on his face again. Can't watch a fellow human being suffer!
(but yeah, that works only with VSTs but it can run in Reason as a plugin itself)

Would love to see Reason properly support multi-core CPUs, and actually had high hopes for Reason 10.

User avatar
EnochLight
Moderator
Posts: 8405
Joined: 17 Jan 2015
Location: Imladris

04 Jul 2018

:o :shock: :?
Win 10 | Ableton Live 11 Suite |  Reason 12 | i7 3770k @ 3.5 Ghz | 16 GB RAM | RME Babyface Pro | Akai MPC Live 2 & Akai Force | Roland System 8, MX1, TB3 | Dreadbox Typhon | Korg Minilogue XD

mrnicehat
Posts: 17
Joined: 03 Mar 2017

04 Jul 2018

jlgrimes wrote:
03 Jul 2018

I hope they at least put a freeze in for 10.5.

Reason's performance actually wouldn't be too bad if they had freeze.
Hi jlgrimmes. Your wish was heard from Propellerhead.
In the new Version 10 update, Freeze is now included:


antic604

04 Jul 2018

EnochLight wrote:
04 Jul 2018
:o :shock: :?
I presume you've seen the new video? :lol:

User avatar
ProfessaKaos
Posts: 477
Joined: 17 Jan 2015
Location: Melbourne, Australia
Contact:

04 Jul 2018

Propellerhead definitely need to address RE and VST performance in Reason, it is quite depressing at times how much worse VST performance is compared to other DAW's.
Reason 12 & 11.3 Suite PC- Windows 10, AMD Ryzen 9 5900x, Asus ROG CROSSHAIR Dark Hero VIII, 64GB G.Skill 3600C16 RAM, 980 Pro Samsung M.2, RTX3060.

https://soundcloud.com/juo-jual
https://www.youtube.com/channel/UCwNLcE ... DjhSI16TqQ

User avatar
Loque
Moderator
Posts: 11175
Joined: 28 Dec 2015

04 Jul 2018

mrnicehat wrote:
04 Jul 2018
jlgrimes wrote:
03 Jul 2018

I hope they at least put a freeze in for 10.5.

Reason's performance actually wouldn't be too bad if they had freeze.
Hi jlgrimmes. Your wish was heard from Propellerhead.
In the new Version 10 update, Freeze is now included:

:D

:cry:
Reason12, Win10

User avatar
tt_lab
Posts: 335
Joined: 15 Jan 2015

04 Jul 2018

Reason is freezing my mac too, and my super windows machine too, eventhou it's not a i9-
Europa almost everytime tends to spike the CPU-
Never had this problem before 10.0

Post Reply
  • Information
  • Who is online

    Users browsing this forum: No registered users and 16 guests