Any performance degradation in Reason on pre-Haswell Windows machines with new MS patch?

This forum is for discussing Reason. Questions, answers, ideas, and opinions... all apply.
drloop
Posts: 243
Joined: 27 Jan 2015
Contact:

12 Jan 2018

EnochLight wrote:
12 Jan 2018
drloop wrote:
12 Jan 2018


Well benchmarking Reasonn is as scientific as it can get since the perfromance is application dependent.

"One of my projects I tested have a combination of REs and VSTs. Reason before patch was using roughly 53% maximum, after the patch it uses 57% maximum load. The average load was 51% before the patch, after the patch average load 53%.
Win10and a i5 3570K."

Avarage load performance after the patch is roughly 4% lower
Peak load performance after the patch is roughly 7% lower

Scientific enough ;)
No, it's not scientific enough. ;) Your approach is subjective, and the percentage you're reporting is an estimate at best.. I much would have preferred using a Reason benchmark songfile and have actual points where the song stops playing back in the transport, instead. Again, I do appreciate the information you provided, though!
I have done that too. With the simple 9.5 benchmark (using R10) I it stops at 1minute and 35seconds. But I have overclocked my my 3560k so my latest test before I overclocked and with Reason 9.5then the test stopped at 1:29. Still good benchmark.


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

12 Jan 2018

drloop wrote:
12 Jan 2018
I have done that too. With the simple 9.5 benchmark (using R10) I it stops at 1minute and 35seconds. But I have overclocked my my 3560k so my latest test before I overclocked and with Reason 9.5then the test stopped at 1:29. Still good benchmark.
Still confused. Are you saying your song benchmark results were 1 minute and 35 seconds before the patch, but 1:29 after the patch?

You overclocked after patching? Or after? Sorry so many questions - just having a hard time interpreting your text.
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

drloop
Posts: 243
Joined: 27 Jan 2015
Contact:

12 Jan 2018

Overclocked and patch 1:35
Stock speed and before patch 1:29

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

12 Jan 2018

drloop wrote:
12 Jan 2018
Overclocked and patch 1:35
Stock speed and before patch 1:29
Thanks. Can you run it again with stock CPU speed and patch?
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

RandyEspoda
Posts: 275
Joined: 14 Mar 2017

12 Jan 2018

EdGrip wrote:
12 Jan 2018
I don't think malware is the worry for anyone here.
I think the worry is about losing DSPs because of a patch which will probably be practically unavoidable for the majority of users.
That's kind of exactly what I was getting at :puf_smile:

I know there are a lot of ppl like me, using an old cpu with win7,
and they don't want to lose 10-15% of its performance.
Those should not install the patch, and simply mind their surf behavior, use things like noscript and ublock or similar, AV, ...
and avoid shady sites. In theory those measures should be able to block any attempts anyway.
"Will antivirus prevent an attack?"
"In theory, an up-to-date antivirus program should block any attacks, but in practice they are – according to security experts – extremely difficult to detect.
The good news is that there is no known malware which exploits these flaws. But it is still a good idea to keep your antivirus, operating system and apps up to date.
Don’t forget to be vigilant when clicking on links in emails and on websites to avoid downloading malware in the first place."
https://www.techadvisor.co.uk/how-to/se ... s-3669697/

EdGrip wrote:
12 Jan 2018
I am not worried about malware OR losing DSPs. For my money, life's too short for worrying about whether or not I need to start coming up with a cunning scheme to avoid a Windows update so that I don't lose the power for the 6th instance of VK-2.
I know that's easy for me to say, but yeesh.
In any case, here are some more bench results scattered throughout this thread, from ppl with old and new systems :
https://forums.mydigitallife.net/thread ... 081/page-2

Those that do seek a future workaround for their pre-haswell cpu and Win7 or 8.1 are best to keep checking that forum too,
as it will stay up-to-date on the subject.

RandyEspoda
Posts: 275
Joined: 14 Mar 2017

12 Jan 2018

And better solutions are already underway, at least for spectre, Google proves :

https://www.bleepingcomputer.com/news/g ... e-attacks/

User avatar
ravisoni
Posts: 420
Joined: 09 Feb 2015
Location: Las Vegas

13 Jan 2018

i5 5300u, 2.3GHz, win10, 8gb, ssd, 3 year old laptop - no decrease in performance (tested after running previously known heavy songs).
:reason: Reason 12 | :re: Preset Browser | :refill: Refill Hoarder

househoppin09
Posts: 536
Joined: 03 Aug 2016

14 Jan 2018

Thanks for the data point, ravisoni. Looks like more confirmation that Win10 users should be pretty much fine, at least. Would love to hear from more Win7/8.1 users about how they're doing with the patch!

33db
Posts: 71
Joined: 26 Nov 2017

15 Jan 2018

The machine I use for recording and video never really gets online, I don't browse or do any of the other things one would do with a day to day computer.
I'm just tossing this in for those of you that can afford 2 machines, and for those that can't think VM's.
Once your recording (or video editing) box is running the way you want why would you ever update it?

User avatar
moneykube
Posts: 3447
Joined: 15 Jan 2015

15 Jan 2018

because it's shiny with that new car smell
https://soundcloud.com/moneykube-qube/s ... d-playlist
Proud Member Of The Awesome League Of Perpetuals

RandyEspoda
Posts: 275
Joined: 14 Mar 2017

16 Jan 2018

househoppin09 wrote:
14 Jan 2018
Thanks for the data point, ravisoni. Looks like more confirmation that Win10 users should be pretty much fine, at least. Would love to hear from more Win7/8.1 users about how they're doing with the patch!
Me too...

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

16 Jan 2018

househoppin09 wrote:
14 Jan 2018
Thanks for the data point, ravisoni. Looks like more confirmation that Win10 users should be pretty much fine, at least.
Wait, what?! Ravisoni is on a post-Haswell chip on Windows 10 (Broadwell). If you're on Windows 10 and a Haswell or older, then you most certainly may notice the double-digit performance hit - according to everything I'm reading anyway.
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

househoppin09
Posts: 536
Joined: 03 Aug 2016

16 Jan 2018

EnochLight wrote:
16 Jan 2018
Wait, what?! Ravisoni is on a post-Haswell chip on Windows 10 (Broadwell). If you're on Windows 10 and a Haswell or older, then you most certainly may notice the double-digit performance hit - according to everything I'm reading anyway.
Judging by the anecdotal reports earlier in this thread and elsewhere, it seems that pre-Haswell Win10 setups are getting very marginal slowdown, if any, in Reason and various other DAWs. In theory, the lack of INVPCID on pre-Haswell chips should make a big difference, but for whatever reason it doesn't seem to be having much effect in practice, at least for audio workloads. The kernel changes made between Win8.1 and Win10 are a different story and seem to be making much more of a difference, which is why the main thing we need at this point is more reports from Win7/8.1 users, regardless of what generation their CPUs are (though pre-Haswell would still be the most telling, of course). It's possible that only the combination of a pre-Win10 kernel and a pre-Haswell CPU will create the conditions that lead to serious performance penalties, but more reports are needed.

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

17 Jan 2018

househoppin09 wrote:
16 Jan 2018
EnochLight wrote:
16 Jan 2018
Wait, what?! Ravisoni is on a post-Haswell chip on Windows 10 (Broadwell). If you're on Windows 10 and a Haswell or older, then you most certainly may notice the double-digit performance hit - according to everything I'm reading anyway.
Judging by the anecdotal reports earlier in this thread and elsewhere, it seems that pre-Haswell Win10 setups are getting very marginal slowdown, if any, in Reason and various other DAWs. In theory, the lack of INVPCID on pre-Haswell chips should make a big difference, but for whatever reason it doesn't seem to be having much effect in practice, at least for audio workloads. The kernel changes made between Win8.1 and Win10 are a different story and seem to be making much more of a difference, which is why the main thing we need at this point is more reports from Win7/8.1 users, regardless of what generation their CPUs are (though pre-Haswell would still be the most telling, of course). It's possible that only the combination of a pre-Win10 kernel and a pre-Haswell CPU will create the conditions that lead to serious performance penalties, but more reports are needed.
If I'm not mistaken, it seems the anecdotal reports also include most users on ASIO audio drivers, which may be something to take into consideration. My worry is that I also use my pre-Haswell-era Windows 10 box as my Plex server as well, and video transcoding is all done on the CPU. :( But if my Reason projects come out of this largely unscathed, that would be awesome.
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

househoppin09
Posts: 536
Joined: 03 Aug 2016

17 Jan 2018

EnochLight wrote:
17 Jan 2018
If I'm not mistaken, it seems the anecdotal reports also include most users on ASIO audio drivers, which may be something to take into consideration. My worry is that I also use my pre-Haswell-era Windows 10 box as my Plex server as well, and video transcoding is all done on the CPU. :( But if my Reason projects come out of this largely unscathed, that would be awesome.
If you're saying you're worried about the video transcoding taking a performance hit from the patch, you can probably stop worrying about that. All the benchmarking I've seen has made a point of looking at video encoding workloads and has concluded that they're not affected to any significant degree.

RandyEspoda
Posts: 275
Joined: 14 Mar 2017

18 Jan 2018

If you're using an older cpu with Win7, here's a simple trick to have the patch installed
without suffering from the 'potential' performance loss, at least while making music.
It involves disabling a registry key when you make music, and enabling it it when doing 'online' business.

1. Install the Windows patch (KB 4073578)

2. Download the following file : https://www.mediafire.com/file/96dd85p1 ... egKeys.zip

It contains two .reg files to enable/disable the M$ fix.
In both cases you need to reboot to apply the registry change.

3.When doing music, first double-click the 'Disable Fix.reg', clear all browser cache and reboot.

Just make sure to stay offline while producing. A healthy workflow anyway...

4.When done producing, double-click the 'Enable Fix.reg' and clear browser cache, reboot.

Best case scenario is that you also clean the file cache and temp files upon every reboot
(singling out the temporary files you actually downloaded too).
If you're into scripting, you can also do a simple script or batch that automates both the reg changes and browser/file cache deletion in one go...


There is now also a program that basically does the same thing as the registry tweaks :

https://www.grc.com/inspectre.htm


Clearing the browser cache is important (best before and after each browsing session), because the malware prone to be released at some point (note that there still isn't any as of yet) would logically focus mostly on browser activity and would inject itself through things like ads and other 'lucrative' js uses to infect a home networked system. Keeping the cache clear before and after each session, combined with only disabling the fix during 'offline' sessions massively reduces the risk of infection and data to be 'read' by the malicious code, even when it is active on your system:

Whenever you're online the patch is active and speculative execution is halted, so the malicious code, 'if' present on your system, will not be able to find any speculative 'secrets' at all. It will be useless, even when installed on your system.
Whenever you're offline with the patch disabled, no malware can get on your system, and if present on your system cannot communicate outside of the pc even with speculative execution enabled and vulnerable for the length of that session.
Combined with a blank browser (and file) cache per session, the risk becomes very minimal.


Since other affected hardware like NVIDIA cards, and most software like AV apps and big names like Google are being mitigated aswell by the vendors, the most obvious and most vulnerable vector for Meltdown and Spectre would continue to be for the most part the browsing habits of the user.

Making sure that you start and end every online session with a blank browser cache
(read: ALL history/cookies/saved sessions&passwords/...deleted),
then whenever you disable the fix and STAY OFFLINE until you enable it again,
It would greatly reduce the risk of actual information theft through infection.
This assumes that you've taken care off all driver and application updates necessary to their latest versions,
and that you don't install any malware or visit sites prone to be infected by it in the first place.
Clean habits produce clean results.

Until better solutions come about this is about the safest way to handle the fixes on old cpu's
while still benefiting full performance during music sessions (or other offline cpu-heavy tasks).
There is already 'Retpolin', developed by Google and already implemented in Linux, that mitigates
all three flaws without any performance loss. Over time it will be implemented by other vendors too (perhaps M$ too ?).
Then it is already known also that older motherboards CAN have their BIOS fixed with the microcode,
although we would have to do it ourselves, and M$ would have to release the actual microcode.
By converting then copying/pasting the microcode into the BIOS rom (there is a specific procedure for it)
it would be a fairly easy process not unlike a BIOS update. Guides for this will eventually become public,
and the way things are going, it will be rather soon than late...

The reason for there still not being any official benchmarks for pre-haswell cpu's on Win7/8.1 is because
there still aren't any official bios updates available for those correlating motherboards,
and so the actual fix with only the M$ patch is still but half complete.

I'll see if I can do some tests on my own 'old' system in the upcoming days/weeks.
I expect losses of between 10-30%...even more for 4K I/O.
I have installed the patch, since it can still be disabled when desired.
It is a Lynnfield on 8gb ram and win7.

Post Reply
  • Information
  • Who is online

    Users browsing this forum: No registered users and 30 guests