Intel's 10nm Problems Might Be Worse Than First Thought

[Dylanc1500]

38 minutes ago, mr moose said:

I thought @Zodiark1593 's posts were fairly accurate.  He didn't say Intel knew definitively about it, but that they made design decisions regarding speculative execution intentionally (which is kinda obvious),  while they knew there was speculation it might be a vulnerability.  I believe that is in line with what @leadeater  pointed out claiming it was more about moving forward with really good odds rather than holding back on a slim maybe.

If everyone held back on possibilities of vulnerabilities nothing would ever be created. There will always be things that can be taken advantage of and become insecure. Everything in this industry is a list of pros and cons, and weeding out cons as you go. Unfortunately for every con taken off a new one emerges. Intel is weighing the cons right now. We will see how they handle it.

[Peskanova]

On 5/8/2018 at 12:20 AM, Waffles13 said:

This is fantastic news.

 

Now, in addition to the know-it-alls in every node thread going "actually, Intel's 10nm node is on par with everyone else's 7nm," we also get to enjoy a new group replying with "actually, Intel's 10nm is now closer to 12nm."

So intel is god? It can be 7 , 10 and 12 at same time?  depends how much of a fanboy are? 

[pas008]

4 hours ago, mr moose said:

I thought @Zodiark1593 's posts were fairly accurate.  He didn't say Intel knew definitively about it, but that they made design decisions regarding speculative execution intentionally (which is kinda obvious),  while they knew there was speculation it might be a vulnerability.  I believe that is in line with what @leadeater  pointed out claiming it was more about moving forward with really good odds rather than holding back on a slim maybe.

intentionally should have not been used

unknowningly I would prolly agree with

and we actually dont know if it was for performance increases on hardware side at all

it was just the way all did it

especially apple considering they take security overly serious

[maartendc]

Ultimately, this is good for the market. If AMD can finally get some prolonged benefit from being ahead in the CPU market, and get some significant market share, they can emerge as a more financially healthy company and stay around for years to come. This provides much needed competition in the market. 

 

I was afraid that Intel would just update their Kaby Lake offerings with twice the amount of cores, and Intel would be ahead again. Fortunately, AMD seems to have a significant lead right now in both architecture and manufacturing process.

 

As for Intel, they have enough cash to withstand a setback like this. They will figure it out sooner or later.

[leadeater]

28 minutes ago, pas008 said:

and we actually dont know if it was for performance increases on hardware side at all

It is, the whole point of speculative execution is the assumption a code path is going to be run so preemptively run it before requested, "Here's one I prepared earlier".

 

A simple example would be executing both sides of a conditional code branch then later when it's know which one is actually needed you have both ready and can hand back the desired one and the other is discarded.

[pas008]

21 minutes ago, leadeater said:

It is, the whole point of speculative execution is the assumption a code path is going to be run so preemptively run it before requested, "Here's one I prepared earlier".

 

A simple example would be executing both sides of a conditional code branch then later when it's know which one is actually needed you have both ready and can hand back the desired one and the other is discarded.

yes but then why is the performance hit percentage wise is non existance on kaby and coffee shouldnt those have taken a hit just liek the rest

along with the fact its like a 25yr old flaw just stuck in cpu design?

[leadeater]

12 minutes ago, pas008 said:

yes but then why is the performance hit percentage wise is non existance on kaby and coffee shouldnt those have taken a hit just liek the rest

along with the fact its like a 25yr old flaw just stuck in cpu design?

Because the microcode updates don't disable speculative execution, it adds memory space protections and changes how speculative execution works. The way it's done has changed over time, each architecture does it slightly different, branch prediction is part of speculative execution and that's one of the key areas to get performance gains. Better hit rate % you get for branch prediction the less CPU stalls you get meaning you don't have to start the execution pipeline again.

[pas008]

12 minutes ago, leadeater said:

Because the microcode updates don't disable speculative execution, it adds memory space protections and changes how speculative execution works. The way it's done has changed over time, each architecture does it slightly different, branch prediction is part of speculative execution and that's one of the key areas to get performance gains. Better hit rate % you get for branch prediction the less CPU stalls you get meaning you don't have to start the execution pipeline again.

and that is my point about being intentional and for performance gains

[Daegun]

15 hours ago, kirashi said:

Turning left at 160mph is an unrealistic and unsafe scenario. Wanting to get the best performance while having 50 Chrome tabs open (or doing any other heavy workload task) is a realistic scenario. You're not comparing apples with apples here, and an average user will indeed notice it if they had doubles of the EXACT same hardware side-by-side running both a patched BIOS and OS on one system, and an unpatched BIOS and OS on the other.

 

Even the manufacturers and software developers have confirmed it will use more hardware resources to help secure things, and yet users are not receiving any compensation for this. In the case of Chrome, users will lose up to 10% of their RAM over this, and with RAM price fixing still at play, it's not even fair to tell people to "just buy more RAM" to help with this increase in usage. https://mobilesyrup.com/2018/07/13/google-chromes-new-meltdown-and-spectre-safeguard-is-a-memory-hog/

This is absolutely an apples to apples comparison, as much as the analogy will allow. It's unrealistic? That's the entire point of the analogy, that it's not a realistic scenario for the average driver to run into, just as the only significantly impacted workloads are something that's not realistic for the average user to run into. The only workloads that were affected more than 3% were ones that were specific to servers, and not even all servers, just certain types.

 

If someone had the exact same hardware side by side, one patched and one not, it would be unlikely that they would be able to tell without some tool like an fps counter or performance numbers from a test to tell them the difference. I haven't noticed anything on my own rig since updating and, being a member of a tech forum, I'm certainly not an average user.

 

Chrome has nothing to do with Intel or the bios and os patches for the processor. They have, admitted by their own team, an incredibly unoptimized patch at the moment that they're working on. If you look at other browsers it's easy to tell that this is an exception and not the rule.

 

 

While spectre and meltdown are both serious, the performance penalties for Intel in particular have been inflated to insanely unrealistic proportions.