Live data from Hacker News

Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

bloomberg.com

561–567 of 567 posts

Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

#561

Earlier quoted context omitted.

Performance is chopped 5-30%, with newer CPU's with PCID being affected less significantly. [0] BoorishBears is possibly pointing out that 30% is a worst case. [0]: https://www.phoronix.com/scan.php?page=article&item=linux-41...

This combined with what the other comment mentions, it's a range from 5%-30% with 30% being a worst case the average user does not encounter. This is an issue, but laypeople are overblowing the effect on their everyday computing.

What about gaming performance? Once everything is patched[0], that is. I know no one knows, but it'll be interesting to see Intel's last remaining advantage (clock frequency) mitigated somewhat by all of this.

[0]https://gist.github.com/woachk/2f86755260f2fee1baf71c90cd653...

Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

#562

Earlier quoted context omitted.

I don't understand this attitude that "top brass might not know about it". He's the CEO, isn't his entire job to know what's going on in the company? I know we get this idea that rich people just sit back and take in the money, but isn't the reason they are paid so much in the first place because they have in theory a big responsibility on what happens in the company?

You're putting words in my mouth. I didn't say he didn't know about it. I said we don't know WHEN he first knew about it, which is important in the context of insider trading.

According to Google, they found out about it in June, and I think it's fair to assume this was shared with Intel shortly after. From the moment it's shared with Intel, it's fair game. It's up to him to setup the company in such a way that important information like this gets to him quickly.

Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

#563
post #541

Earlier quoted context omitted.

50%, rather, is the worst case scenario. 30% is a bad case scenario, and 5% best-case scenario. Which is still a lot for large cloud providers like amazon, google, microsoft.

Any public information on how someone like Google or Facebook handle this? Do they have enough spare capacity to patch or will they need to build further capacity first? I could imagine 10% of Google's capacity (internal services, not Google Cloud) is at least a large datacentre.

I know someone who works for amazon and he said that they didn't need to do anything or buy any more servers.

Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

#564
post #560

Earlier quoted context omitted.

"dollar cost averaging is your friend" Research suggests otherwise: https://personal.vanguard.com/pdf/ISGDCA.pdf Diversification is a more effective strategy for dealing with volatility.

I only read page one of that link (thanks for sharing), but it appears to limit its scope to a specific scenario: given a lump sump of money (a windfall), it is it better to invest all at once or dollar cost average over a period of time? It is not recommending against dollar cost averaging in general; it is recommending against it for windfalls. Diversification is also not mentioned in the article.

I read that Vanguard study when it came out, yes it's correct statistically but I disagree with using that data to do lump sum investments. For one, the CEO in their 2018 outlook webcast said to DCA. Even if you keep a short timespan on your DCA (I do 26 weeks), it's a good idea for your mental health if you happen to dump it all right before a collapse.

Sometimes it's wiser to take into account human psychology, even if academics are out there with data to convince us otherwise.

I'm personally with the CEO of Vanguard on this one. A short entrance into the market, especially in today's situation is probably the way to go. People can do whatever they want, and if they put their money where their mouth is and go in with a lump sum, then I'll respect it.

Otherwise, as someone who is bringing a lot of money myself onto the market now, I'm DCAing.

Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

#565

Honest question, does the performance hit from this patch actually hit Intel's best processors enough to make them perform worse than AMD's best? I don't keep up on these kinds of metrics, but I'm under the impression that Intel still dominated CPU benchmarks berfore this issue, so if this question is answered in the negative then I doubt it will affect Intel very much.

It's too soon to say. There's still variants Meltdown/Spectre that aren't fixed yet. The other guy was correct that it probably depends on your workload, but in a couple months after all the dust has settled on this and we have a comprehensive review, my guess is yes AMD is going to take a commanding lead.

Spectre affects every modern CPU, and performance impact will be marginal. Meltdown affects Intel-only, and the performance impact will be significant. Here's Fortnight's preliminary server results[0].

Once everything[1] is patched up it's just going to get worse for Intel. Ryzen was already fast though and had superior SMT (Hyperthreading) efficiency than Intel prior to this bug (~10%). This is going to take a serious toll on Intel's single-threaded performance advantage (~10% from IPC, 25% clock frequency advantage).

My advice is to stick with Ryzen/Threadripper/Epyc.

[0]https://www.epicgames.com/fortnite/forums/news/announcements...

[1]https://gist.github.com/woachk/2f86755260f2fee1baf71c90cd653...

Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

#566

Earlier quoted context omitted.

About 10 years ago I was mentored by a guy who was an utter wizard at queuing theory, and who bugfixed a whole bunch of nasty issues in cellular telecoms hardware through his understanding of how queuing theory impacted code execution. TL:DR - queue behaviour gets nonlinear as you approach the theoretical max load. If you are running your processors at a high load, even a small change in code throughput makes a huge…

I believe I saw a strangeloop talk about this specific issue in Clojure. The talk giver was talking about channels, not queues though.

Do you have a link?

Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

#567
post #513
post #511

Earlier quoted context omitted.

Imagine that you are the person leading the team that's making an embedded system on an ARM SOC. It's not Linux, so you have your own boot code, drivers and so forth. It's not just a matter of "welp, get another kernel image." You're doing everything from the bare metal on up. (I should remark that there are good reasons for this effort. Such as: It boots in under 500ms, it's crazy efficient, doesn't use much RAM, an…

The responsibility to document the quirks and necessary workarounds lie with the manufacturer of the hardware. If the manufacturer doesn't provide the necessary documentation, then that's exactly that: insufficient documentation to use the device. There are hardware manufacturers that are better than others at being open and providing documentation. My minimal level of required support and documentation right now is…

> The responsibility to document the quirks and necessary workarounds lie with the manufacturer of the hardware.

When you buy an SOC, the /contract/ you have with the chip company determines the extent and depth of their responsibility. On the other hand, they do want to sell chips to you, hopefully lots of them, so it's not like they're going to make life difficult.

Some vendors are great at support. They ship you errata without you needing to ask, they are good at fielding questions, they have good quality sample code.

Other vendors will put even large customers on a tier-1 support by default, where your engineers have to deal with crappy filtering and answer inane questions over a period of days before getting any technical engagement. Issues can drag on for months. Sometimes you need to get VPs involved, on both sides, before you can get answers.

The real fun is when you use a vendor that is actively hiding chip bugs and won't admit to issues, even when you have excellent data that exposes them. For bonus points, there are vendors that will rev chips (fixing bugs) without revving chip version identifiers: Half of the chips you have will work, half won't, and you can't tell which are which without putting them into a test setup and running code.

Post reply on HN