Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

bloomberg.com

Post reply on HN
Print view View original

231–240 of 567 posts

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

#231

Post by mtanski »

3pt14159 wrote: post #223
mtanski wrote: post #145

Earlier quoted context omitted.

As I mentioned in the other thread yesterday database and database like applications are going to be hit particular hard. Even more so on fast flash storage. Double whammy compared to apps just doing network IO. And while databases try to minimize the number of syscalls they still end up doing a lot of them for read, writeout, flush.

Do we have a performance estimate? I can eat 20 or 30%, but I can't eat 90%.

This comment further down thread mentions it's 20% in Postgres. https://news.ycombinator.com/item?id=16061926

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

#232

Post by nopriorarrests »

chrisper wrote: post #180

If you look here: https://www.computerbase.de/2018-01/intel-cpu-pti-sicherheit... (Sorry it is German) But if you scroll down to "Windows-Benchmarks: Anwendungen" you can see that most applications do not have any performance hit with the Windows patch. Only M.2 SSD seem to be affected.

All their tests are CPU-bound, not IO-bound, namely -- archiving, rendering, encoding video. Performance degradation happens with transactional, IO-bound tasks (think noSQL databases, ad serving, trading)

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

#233

Post by ComodoHacker »

dsign wrote: post #19

This is a clusterf /big deal. Beyond the security implications, it means that all companies paying for computing resources will have to pay roughly 30% more overnight on cloud expenses for the same amount of CPU, assuming that they can just scale up their infrastructure. I know that bugs happen and that there was nothing intentional on this one, but at times like this is hard to held at bay the temptation of claiming…

Forgive me my ignorance, but I fail to see how this is such a big deal. Even 50% performance hit/cost increase would be... bearable, computations are rather cheap today. ML and other intensive calculations aren't done on CPU anyway. It's not like technical progress of our civilization is slowed down by 30% or something...

On the other hand, shrinking Intel's market share due to bad PR and thus adding some competition into the industry could actually foster that progress.

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

#235

Post by kabdib »

spdy wrote: post #77
zouhair wrote: post #69

Earlier quoted context omitted.

This is typically what happens when you go for a long time without real competition. You get way too comfortable and bad habits start to pile up.

Isn't why this problem even exits the exact opposite? Intel was losing on the mobile market and changed internal testing to iterate faster by cutting corners. Found a quote: "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 comp…

Man, you should see the errata for some ARM-based SOCs. It's amazing that they work at all.

Vendor, in conversation: "We're pretty sure we can make the next version do cache coherency correctly."

Me (paraphrased): "Don't let the door hit you in the ass on the way out."

Management chain chooses them anyway, I spend the next year chasing down cache-related bugs. Fun.

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

#236

Post by cortesoft »

prudhvis wrote: post #173
oliwarner wrote: post #114

Earlier quoted context omitted.

As a billion other people have already said, that all depends on their workloads. This isn't a 30% clockspeed deduction.

As i understand the problem, this isn't about clockspeed reduction, now it is the software's responsibility to check if the page is a kernel page/user page. So, the impact is significant. So, every time either pages are touched/accessed this check needs to be triggered, which causes it to be much slower.

Right, but how often that happens is workload dependent. Basically, how often is your code making syscalls.

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

#237

Post by hinkley »

chx wrote: post #98
dzink wrote: post #20

Didn’t the Intel CEO just sell half of his shares/options? If he knew about these issues isn’t that illegal?

You can be sure there's a young hotshot with sparkling eyes at SEC who is already typing a letter to Mr. Krzanich politely asking about the circumstances of that sell. At the same time, noone is doing eight figures transactions which require reporting to the SEC without talking to a lawyer. Right? Right? They really dislike insider trading, it's one of the few things where even rich people can get imprisoned -- and t…

It's a good thing.

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

#238

Post by sbarre »

olfactory wrote: post #185
jk563 wrote: post #181

Earlier quoted context omitted.

Well if you use m5.xlarge instances from AWS you were getting 4 vCPUs for your money. I don't expect you'll now get 5...

No, but the underlying hardware that perviously hosted two m5.xlarge instances may instead host one M5.xlarge and one M5.medium, so that performance is not degraded.

Yeah but AWS doesn't guarantee that "2x m5.xlarge" will meet any kind of performance requirements, particularly your own application's, do they?

So you may suddenly find that your own performance requirements, that were previously satisfied by "2x m5.xlarge" are no longer being met by that configuration, and I doubt AWS will just provide you with more resources at no additional charge.

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

#239

Post by cdoxsey »

ComodoHacker wrote: post #233
dsign wrote: post #19

This is a clusterf /big deal. Beyond the security implications, it means that all companies paying for computing resources will have to pay roughly 30% more overnight on cloud expenses for the same amount of CPU, assuming that they can just scale up their infrastructure. I know that bugs happen and that there was nothing intentional on this one, but at times like this is hard to held at bay the temptation of claiming…

Forgive me my ignorance, but I fail to see how this is such a big deal. Even 50% performance hit/cost increase would be... bearable, computations are rather cheap today. ML and other intensive calculations aren't done on CPU anyway. It's not like technical progress of our civilization is slowed down by 30% or something... On the other hand, shrinking Intel's market share due to bad PR and thus adding some competition…

If you run things efficiently you're eaking every ounce of performance out of this hardware. A 30% performance hit means a 30% cost increase.

The bigger issue is for things that don't scale easily. That sql server that was at 90% capacity is suddenly unable to handle the load. Sure that could've happened organically, but now it happens (perhaps literally) overnight for everyone all at once.

Expect a bunch of outages in the next few weeks as companies scramble to fix this.

Post reply on HN