8700k Microcode Updates / Planned obsolescence. Cinebench r15, Win11

[DarkSmith2]

Win11 8700k 5GHz, without Microcode Updates:

 

Winn11 8700k 5GHz, with Microcode Updates:

 

Without running custom timer, via timer resolution tool (as service) The difference is even bigger. Straight stock installation w/o tweaking my 8700k gets around 1600points, disabling the mcu boosts it to 1670points. The difference is worth about 200-300mhz in performance. Last time ive did a comparison the impact to the performance of the Microcode update wasnt as big. 

So is it the Win11 Scheduler, or is it planned obsolescence? What do you think?

[Levent]

That is 2% difference. I dont even consider anything less than 10% noticeable or relevant in any benchmark. There is nothing here that resembles any sort of planned obsolescence, it is just your OCD talking.

[DarkSmith2]

2 minutes ago, Levent said:

That is 2% difference. I dont even consider anything less than 10% noticeable or relevant in any benchmark. There is nothing here that resembles any sort of planned obsolescence, it is just your OCD talking.

not good in math huh? 1693/100=16.93 difference: 61/16.93= 3.60%
And 10% difference not relevant? 10% difference is the difference worth of 500Mhz, so you say you dont care if you get the performance of 4500mhz vs 5000mhz? 

[tikker]

10 minutes ago, DarkSmith2 said:

not good in math huh? 1693/100=16.93 difference: 61/16.93= 3.60%
And 10% difference not relevant? 10% difference is the difference worth of 500Mhz, so you say you dont care if you get the performance of 4500mhz vs 5000mhz? 

I don't see this 10% difference anywere. A 1693 to 1632 drop is a drop of (1632 - 1693) / 1693 = 3.6%. An increase from 1600 to 1670 is (1670 - 1600) / 1600 = 4.4%. That increase is not trustworthy anyway, because you say "around 1600", but when we are talking about scores that literally differ by only dozens you need a more precise number than "around". Finally, because runs can vary you need to do like 10 runs on each setting to get an average score and a feel for the natural spread in scores.

 

25 minutes ago, DarkSmith2 said:

or is it planned obsolescence?

No. Can people stop throwing this term around for every single thing that breaks or loses a small bit of performance? It's becoming the new bottlenecking.

[Guest]

I am just wondering why CBR-15? 

 

The benchmark is easily manipulated. So 3% is really nothing to worry about.

[Levent]

30 minutes ago, DarkSmith2 said:

not good in math huh? 1693/100=16.93 difference: 61/16.93= 3.60%
And 10% difference not relevant? 10% difference is the difference worth of 500Mhz.

Yes, 3.6% is as pointless as 2% gains unless you are playing the numbers game. Increase is CPU clocks does not mean in equal increases in scores. 

30 minutes ago, DarkSmith2 said:

so you say you dont care if you get the performance of 4500mhz vs 5000mhz? 

If performance scales with the overclock, I would, if it doesnt I wouldnt. I gain less than 5% in CB15 scores with 200mhz overclock while having 15% more vcore, 20% more power consumption.

[DarkSmith2]

18 minutes ago, tikker said:

I don't see this 10% difference anywere. A 1693 to 1632 drop is a drop of (1632 - 1693) / 1693 = 3.6%. An increase from 1600 to 1670 is (1670 - 1600) / 1600 = 4.4%. That increase is not trustworthy anyway, because you say "around 1600", but when we are talking about scores that literally differ by only dozens you need a more precise number than "around". Finally, because runs can vary you need to do like 10 runs on each setting to get an average score and a feel for the natural spread in scores.

i asked @levent if he is alright with a 10% difference. Not stated anywhere that it is a 10% difference, please read before making things up, i also did the math in my previous post. Thank you.

 

19 minutes ago, tikker said:

No. Can people stop throwing this term around for every single thing that breaks or loses a small bit of performance? It's becoming the new bottlenecking.

well if the performance decreases unreasonably more and more over time due to updates that is what its called.

[DarkSmith2]

1 minute ago, ShrimpBrime said:

I am just wondering why CBR-15? 

 

The benchmark is easily manipulated. So 3% is really nothing to worry about.

CBR-15 because i used it previously often, so i can compare more easily for myself. Thats the only reason.

[Hairless Monkey Boy]

Nothing burger.

 

While I understand the impulse to be upset by a drop in performance, I really don't see this as a big deal at all. If you never ran the benchmark, you never would have noticed.

[DarkSmith2]

10 minutes ago, HairlessMonkeyBoy said:

While I understand the impulse to be upset by a drop in performance, I really don't see this as a big deal at all. If you never ran the benchmark, you never would have noticed.

yea well regardless im not running the updates anyways, cause they dont fullfill any purpose successfully. Just wanted to point out that the performance hit is getting bigger and bigger.

[tikker]

33 minutes ago, DarkSmith2 said:

i asked @levent if he is alright with a 10% difference. Not stated anywhere that it is a 10% difference, please read before making things up, i also did the math in my previous post. Thank you.

Well you are the one making up this 10% difference. No point in asking if someone is ok with a 10% difference if there is none. [edit] ah ok, I see, this is about whether someone considers 10% relevant. Missed that.[/edit]

 

You should run multiple tests on either scenario as well to actually quantifiy this difference.

33 minutes ago, DarkSmith2 said:

well if the performance decreases unreasonably more and more over time due to updates that is what its called.

No. We've seen from the metldown and spectre fixes that it's not unlikely for security updates to have an impact on performance. That's not planned obsolescence, that's unfortunate reality. I don't know what's in this specific microcode update, but be glad Intel prefers to push a (security) update knowing there's a performance hit versus not fixing it out of fear for a vocal minority being angry about a few % performance hit that most likely will only be noticeable in benchmarks.

[Guest]

38 minutes ago, DarkSmith2 said:

CBR-15 because i used it previously often, so i can compare more easily for myself. Thats the only reason.

All good, was only curious.

 

I also am running W11 on 8700K (without the TPM bullshit) but I can say there's no real loss in performance from W10 while Winblows 10 is horrible for legacy benchmarking (IMO of course)

[YoungBlade]

One benchmark is meaningless for determining a performance difference. Also, I would guess that the microcode update is to deal with potential flaws (Spectre/Meltdown style) and that in order to maintain stability while mitigating those issues, the clocks have to drop a bit. That's not planned obsolescence, that's just the reality of such fixes.

[DarkSmith2]

38 minutes ago, tikker said:

No. We've seen from the metldown and spectre fixes that it's not unlikely for security updates to have an impact on performance. That's not planned obsolescence, that's unfortunate reality. I don't know what's in this specific microcode update, but be glad Intel prefers to push a (security) update knowing there's a performance hit versus not fixing it out of fear for a vocal minority being angry about a few % performance hit that most likely will only be noticeable in benchmarks.

well im not having a problem with them trying to fix security, im having a problem with taking a performance hit while the security updates are insufficient with no choice/option to use or not use them, you cant deactivate those security features unless you modify stuff.

 

The less educated and less experienced user is quite "forced" to run this placebo updates at the cost of performance and this is what it makes morally reprehensible. But thats overall a different topic in itself.

[YoungBlade]

5 minutes ago, DarkSmith2 said:

well im not having a problem with them trying to fix security, im having a problem with taking a performance hit while the security updates are insufficient with no choice/option to use or not use them, you cant deactivate those security features unless you modify stuff.

 

The less educated and less experienced user is quite "forced" to run this placebo updates at the cost of performance and this is what it makes morally reprehensible. But thats overall a different topic in itself.

Taking a 3% performance hit in an application that no one uses anymore for the sake of improving security is the last thing I would label as "morally reprehensible." And, frankly, a less experienced user would never even notice such an insignificant performance hit.

[DarkSmith2]

2 minutes ago, YoungBlade said:

Taking a 3% performance hit in an application that no one uses anymore for the sake of improving security is the last thing I would label as "morally reprehensible." And, frankly, a less experienced user would never even notice such an insignificant performance hit.

well "placebo" security, there is no point in creating security where the vulnerability is only present when the attacker already has to have full access over your PC in some sort. Also useless if an attacker knows all my passwords and everything is protected via 2fa / tokens. So its not real "security" its just placebo.

[YoungBlade]

1 minute ago, DarkSmith2 said:

well "placebo" security, there is no point in creating security where the vulnerability is only present when the attacker already has to have full access over your PC in some sort. Also useless if an attacker knows all my passwords and everything is protected via 2fa / tokens. So its not real "security" its just placebo.

Are you claiming that Intel fabricated or exaggerated the need for this update to give them an excuse to handicap one of their own products?

[DarkSmith2]

Just now, YoungBlade said:

Are you claiming that Intel fabricated or exaggerated the need for this update to give them an excuse to handicap one of their own products?

No, im saying i want officially the choice of weither i use security updates or not. I bought a product based on its performance, and i dont want its performance to be forcefully reduced via software for reasons that i dont care about. All i want is an "on/off" button.

[Mister Woof]

Every time there's a security fix we lose a little.

 

This is old news by now.

 

[DarkSmith2]

Just now, Mister Woof said:

Every time there's a security fix we lose a little.

 

This is old news by now.

 

in the good old days, updates had the purpose to increase performance, now its all about "security".. all the old CPUs dont get that updates and nobody is suffering more from attacks or any malicious stuff, so whats the point of them updates?

[Mister Woof]

14 minutes ago, DarkSmith2 said:

in the good old days, updates had the purpose to increase performance, now its all about "security".. all the old CPUs dont get that updates and nobody is suffering more from attacks or any malicious stuff, so whats the point of them updates?

Well things have certainly changed. Security is pretty important these days.

 

If you want, you can not update your BIOS or use a different operating system.

 

I'm using Windows 11 and haven't noticed any significant performance differences. 

 

In R23, it was around 17100 before and around 17100 after - give or take.

[xg32]

29 minutes ago, DarkSmith2 said:

.

4% is very significant imho, while ocing we get 1-2% increments.

 

The 8700k gets hit the hardest by the updates, even the 9900k gets fked, just comparing to the 10700k on more recent results shows that.

 

I'd avoid the updates if possible.

[Ebony Falcon]

More testing on a clean system needs to be done 

[TeraBot452]

also windows could have been using 3% of the cpu at that time.  Which would result in the score

[DarkSmith2]

42 minutes ago, Ebony Falcon said:

More testing on a clean system needs to be done 

 

17 minutes ago, xXGaming123 said:

also windows could have been using 3% of the cpu at that time.  Which would result in the score

 

It was on a fresh/clean installed system, there was no load/other software running on the CPU during the tests, the test was done multiple times, also after restarts.