Serious Intel CPU bugs (2016) • Hacker News Board

Re: Serious Intel CPU bugs (2016)

#61

Post by marcosdumay » Wed, Jan 03, 2018, 2:36 PM UTC

baq wrote: post #27

slivym wrote: post #13

As a former Intel employee this aligns closely with my experience. I didn't work in validation (actually joined as part of Altera) but velocity is an absolute buzzword and the senior management's approach to complex challenges is sheer panic. Slips in schedules are not tolerated at all - so problems in validation are an existential threat, your project can easily just be canned. Also, because of the size of the compa…

not quite true regarding the focus - you aren't building a $50B+ company when you don't have focus, it's just that their core compentency isn't fashionable right now. they can't grow in the markets they're in because they either own them completely or were driven out, so they're trying different ones (pivoting, if that's applicable to mature companies).

They had a presence on the currently faster growing market (mobile), but they decided to sell it a while ago because it wasn't trendy and margins were smaller.

Now they are pivoting everywhere, but theirs is the only market with sufficient margins. And the perspective is that their margins will shrink because of competition and software emulation (that they are keeping into control by patent trolling).

Re: Serious Intel CPU bugs (2016)

#62

Post by dspillett » Wed, Jan 03, 2018, 3:24 PM UTC

static_noise wrote: post #55

dspillett wrote: post #43

Earlier quoted context omitted.

> "we can’t live forever in the shadow of the early 90’s FDIV bug" There is a valid point there though - if you are testing for testing's sake and not finding anything extra through the extra effort then you are wasting time and potentially worse: lulling yourself into a false sense of security. Testing should be done for utility, not just in response to fear - you need to test intelligently, not just test lots. Like…

Testing is not for finding bugs, testing is for preventing bugs. But otherwise you are right, it's hard to calibrate and further develop the testing procedure if you rarely find bugs. While you might wide awake on one eye you might be blind on seven others. It's usually the things you don't expect that kill you. So, some need to be paranoid, be very paranoid.

The current chip bug does look like a doozy...

See https://www.theregister.co.uk/2018/01/02/intel_cpu_design_fl... if you've not already picked up on the news.

Re: Serious Intel CPU bugs (2016)

#63

Post by walterbell » Wed, Jan 03, 2018, 3:36 PM UTC

_0w8t wrote: post #53

I can only expect that future will be worse. It may be that VM providers will find it unprofitable to offer a VM capable of running generic native code. Another thing that security products for desktops like Qubes OS that rely on hardware isolation to run untrusted code may need to reconsider their business model.

What’s the connection between the performance hit of this bug and Qubes’ business model?

Re: Serious Intel CPU bugs (2016)

#64

Post by mtgx » Wed, Jan 03, 2018, 3:39 PM UTC

As someone who worked in an Intel Validation group for SOCs until mid-2014 or so I can tell you, yes, you will see more CPU bugs from Intel than you have in the past from the post-FDIV-bug era until recently.
Why?
Let me set the scene: It’s late in 2013. Intel is frantic about losing the mobile CPU wars to ARM. Meetings with all the validation groups. Head honcho in charge of Validation says something to the effect of: “We need to move faster. Validation at Intel is taking much longer than it does for our competition. We need to do whatever we can to reduce those times… we can’t live forever in the shadow of the early 90’s FDIV bug, we need to move on. Our competition is moving much faster than we are” - I’m paraphrasing.

Many of the engineers in the room could remember the FDIV bug and the ensuing problems caused for Intel 20 years prior. Many of us were aghast that someone highly placed would suggest we needed to cut corners in validation - that wasn’t explicitly said, of course, but that was the implicit message. That meeting there in late 2013 signaled a sea change at Intel to many of us who were there. And it didn’t seem like it was going to be a good kind of sea change. Some of us chose to get out while the getting was good. As someone who worked in an Intel Validation group for SOCs until mid-2014 or so I can tell you, yes, you will see more CPU bugs from Intel than you have in the past from the post-FDIV-bug era until recently.

So this is why Krzanich sold his stock. He knows the bug is his fault. Whoops. I think someone may "quit for personal reasons" soon.

https://www.fool.com/investing/2017/12/19/intels-ceo-just-so...

Re: Serious Intel CPU bugs (2016)

#65

Post by mtgx » Wed, Jan 03, 2018, 3:43 PM UTC

chrisper wrote: post #5

So I recently bought an 8700k. I was wondering if I should rather return it and get AMD instead? Not sure how much the recent bugs will impact me performance wise.

8700k is an "end of the line" CPU in terms of motherboard support. Also AMD Ryzen CPUs give you much better bang for buck.

Re: Serious Intel CPU bugs (2016)

#66

Post by p0nce » Wed, Jan 03, 2018, 3:45 PM UTC

sqldba wrote: post #44

p0nce wrote: post #37

Earlier quoted context omitted.

> Kind of similar to the often repeated quality triangle in Software dev Which was disproved in practice.

Can you back this up? I googled and didn’t find anything relevant.

Yes I can.

https://www.amazon.fr/Economics-Software-Quality-Capers-Jone...

Not all good content is offered for free on the Internet.

Re: Serious Intel CPU bugs (2016)

#67

Post by pier25 » Wed, Jan 03, 2018, 3:52 PM UTC

It annoys me when some online content (or edit) hasn't a date explicitly stated.

Re: Serious Intel CPU bugs (2016)

#68

Post by hungerstrike » Wed, Jan 03, 2018, 4:05 PM UTC

All the CPUs in my house are 4th and 5th generation Intel CPUs except for one PC laptop that has a Skylake processor.

I guess I'm glad now that Apple put a 2 year old CPU in the early 2015 Macbook Pro! Besides my 2012 Mac Pro, that is the most expensive machine in the house!

Re: Serious Intel CPU bugs (2016)

#69

Post by dannyw » Wed, Jan 03, 2018, 4:13 PM UTC

mehrdadn wrote: post #57

dannyw wrote: post #49

Earlier quoted context omitted.

Under Australian law, it depends on if the defect is material, and if it would have reasonably changed your buying decision. A 30% performance reduction (like the page table isolation fixes) probably would be considered material.

> Under Australian law, it depends on if the defect is material, and if it would have reasonably changed your buying decision. Interesting, so if you need that particular product (say it has something specific you need, e.g. a program that only runs well on Intel) and there is no competitor to it with that particular feature (e.g. AMD CPU runs the program poorly) then they can sell you as otherwise-defective of a pro…

Interesting point. I don't know if this has ever been tested in court, and I am not a lawyer, especially a consumer law lawyer, but I reckon the court system would probably handle it in some way. The ACL is written to be quite equitable, and courts have generally interpreted it as such.

Re: Serious Intel CPU bugs (2016)

#70

Post by badsectoracula » Wed, Jan 03, 2018, 4:21 PM UTC

kuschku wrote: post #29

badsectoracula wrote: post #19

Earlier quoted context omitted.

> or even OpenGLs immediate mode (which does one syscall per emitted vertex, in worst case) Perhaps with drivers written in the 90s for hardware from the 90s. Any OpenGL implementation worth its salt will buffer those requests on the client side until they need to be observed. Indeed this was a big feature in the heyday of DirectX 9 where D3D programmers had to count the drawcalls whereas with OpenGL you have way mor…

That's why I said in absolute worst case scenario. I know that in the past I actually wrote some program in high school that did use that. Nowadays, thanks to vulkan and AZDO with glMultiDrawElementsIndirect, you're right, of course — you might even use a single syscall per frame. That's why I said, in absolute worst case.

No i meant explicitly about the part i quoted: the immediate mode. Stuff like glBegin, glVertex3f, glEnd, etc. Those will not get you a syscall per vertex, they will be buffered by the OpenGL implementation. Modern OpenGL implementations, at least those by Nvidia and AMD (and i also suspect Mesa too) do a lot of optimizations on the client side.