Spectre patch tested on the iPhone 6 - 40% DROP in both single and multi core performance

[Valentyn]

9 hours ago, RagnarokDel said:

That's not how you do benchmarks...

 

9 hours ago, leadeater said:

True but even with the improper testing method if there was 40% drop you'd see it as that's far greater than per unit performance variant.

Ding ding. Someone gets it. A 40% performance loss would instantly be seen; even with the variance between units.

 

There’s only one source for this supposed result, and no one has been able to replicate it. Yet somehow some places are just running with it as news. 

 

The reddit post about it has already disappeared off the Apple front page and they love controversy.

As not a single user was able to replicate the 40% drop.

[ScratchCat]

6 hours ago, System Error Message said:

unlike x86 CPUs that laugh at ARM in performance (both math and logic), many apps have a bloated UI that makes use of the CPU. With geekbench scores much lower, for sure your UI responsiveness is going to be lower. For instance in many mobile apps, the UI itself has so much code to track your touch and activities of the phone itself (like networking).

 

So phones are going to be sluggish. If your phone uses a generic ARM CPU, the impact is not so bad, snapdragons with custom qualcomm chips will suffer a bigger performance hit than generic arm but will still perform better.than generic ARM.

Apps generally should use event driven where possible as this does not require the same extent of polling which causes the higher load. Additionally most of Apple's SoCs have had excess amounts of single thread performance such that a drop will not be noticed by many users / obscured by transitions.

 

Much of the UI also depends on factors other than CPU performance such as storage speed , which in the case of Apple's Nvme SSDs will be affected to a greater extent by the patch for Meltdown.

 

Additional Note: No performance deficit noticeable on a 5S.

[System Error Message]

5 minutes ago, ScratchCat said:

Apps generally should use event driven where possible as this does not require the same extent of polling which causes the higher load. Additionally most of Apple's SoCs have had excess amounts of single thread performance such that a drop will not be noticed by many users / obscured by transitions.

 

Much of the UI also depends on factors other than CPU performance such as storage speed , which in the case of Apple's Nvme SSDs will be affected to a greater extent by the patch for Meltdown.

 

Additional Note: No performance deficit noticeable on a 5S.

Social apps which are very commonly used, are resource hogs, both on PCs and phones. Hence why battery life and performance will suffer.

[juri-han]

on my iphone X the score went up lmao

[potoooooooo]

Was he using canned scores from geekbench for the result, and then comparing to his? Looks like he has a degraded battery in his unit and is comparing to healthy iphones.

[Amy R]

Not really noticeable performance drop on iPhone 7 after 1 year of use, and after the update patch too. Better get a new update or the attack will destroy user device later.

somehow those both vulnerable meltdown and spectre really scary.

[RadiatingLight]

17 hours ago, Brooksie359 said:

Wait I thought you only needed to us are the bios for meltdown not specter? Maybe I am wrong but that's what I had thought others had said.

Could be, haven't looked into it too much.

AFAIK spectre is partially unfixable, but IDK

[Zodiark1593]

10 minutes ago, RadiatingLight said:

Could be, haven't looked into it too much.

AFAIK spectre is partially unfixable, but IDK

For a lot of mobile big.Little architectures (potentially Apple included), this could actually be fixable without a hardware change, though it involves disabling use of the big cores as that is where the vulnerabilities are.

[RadiatingLight]

21 minutes ago, Zodiark1593 said:

For a lot of mobile big.Little architectures (potentially Apple included), this could actually be fixable without a hardware change, though it involves disabling use of the big cores as that is where the vulnerabilities are.

Yeah... Nobody will do that though.

but it's not reasonably possible to fix.

[Zodiark1593]

3 minutes ago, RadiatingLight said:

Yeah... Nobody will do that though.

but it's not reasonably possible to fix.

Agree, not without eating a giant performance penalty anyway.

 

Though I suppose this depends on whether the security issue is dire enough to disable the big cores. Spectre and Meltdown don't seem to be quite there, though lack of any information for the past week is a little perturbing.

[Guest]

On 14/01/2018 at 2:43 AM, tjcater said:

Sure it suffers in a benchmark, but will games/apps/UI experience a difference? The impact for regular desktop users (E.g. using mostly non IO intensive applications) was negligible and most games had a loss under 1%.

Theres no difference. This article belongs in the trash.

[Bit_Guardian]

18 hours ago, ScratchCat said:

Apps generally should use event driven where possible as this does not require the same extent of polling which causes the higher load. Additionally most of Apple's SoCs have had excess amounts of single thread performance such that a drop will not be noticed by many users / obscured by transitions.

 

Much of the UI also depends on factors other than CPU performance such as storage speed , which in the case of Apple's Nvme SSDs will be affected to a greater extent by the patch for Meltdown.

 

Additional Note: No performance deficit noticeable on a 5S.

Nope, responsive streams took over event-driven ages ago, as responsive apps cache the returned results of many activities and use priming functions for API post functions to provide all the security validation and such. Then all that's left is a 1-bit response to provide a yes/no, and all the heavy processing is done before you've even clicked "accept" before the service layer commits the change to database.

 

You don't even need AI for it, just vector checks over a few hundredths of a second, to be faster than event-driven could ever hope to be.