V8: Workaround for Intel Gemini Lake Processor Bug
chromium-review.googlesource.com
chromium-review.googlesource.com
This is a great one to start with, "24-core CPU and I can’t type an email": https://randomascii.wordpress.com/2018/08/16/24-core-cpu-and...
Can you elaborate on this? I've never heard this before.
Intel is 1 year late on delivering a Jasper lake (Gemini lake refresh,) Tremont is also way too late. Elkhart lake (Xeon branded Atom) delayed indefinitely. Skyhawk lake is said to arrive 2Q-3Q late next year.
Mercury lake seem to be certainly cancelled as early buyers are getting refunds after 2 years of repeated shipping delays
And yes, the "Intel's Saviour" Lakefield is just coming out of fabs as we speak
Chinese laptop OEMs are scratching their heads very hard now. All want to jump the ship for AMD, but Intel holds them hostage through completely anticompetitive "preferred partner" agreements
Things are so bad among OEMs in China that people are now making laptops with desktop chips
Is it just me or it's an actual trend ?
https://mattstoller.substack.com/p/the-coming-boeing-bailout
Is it simply cognitive bias at work, like LessWrong often says? But I think there must be deeper reasons than that. Did anyone write good books on this subject? Either sociology, psychology, management & decision-making or economics prospective is welcomed.
It's short-termism, which is a common threat to society at large. Think of cities that build in sites vulnerable to earthquakes or floods, for example. After the event hits, everyone says, "Oh, we will never do that again," and it is true for approximately one generation. Then, unless the culture has evolved to value metrics coinciding with these kinds of long-term sustainability issues, they immediately start to relax any preventative policies.
In business, all the cycles are shorter, there's always a "new thing", and next to nobody has the kind of deep institutional experience you would see in a big topic like city planning. Thus the valuation metrics of all agents will quickly fall to current market pricing, and competition may act to hold those metrics in place - if you are the only restaurant in town that doesn't cut corners, customers will complain about how overpriced you are. Regulation, labor and consumers exercising their power all have a role in changing what a business can or can't do by raising the floors on acceptable practice.
But let's say you are exceptionally good at operating a restaurant on your own - quality everywhere - and grow to have a chain. Now you need to hire managers, and the viable hiring pool consists of the people who were cutting corners before - because there is literally nobody else out there. Good luck retraining them!
Plus, at the corporate scale, you end up with fiefdoms and power struggles leading to metrics that agree with the current internal political situation, not industry or marketplace factors, and certainly not sustainability metrics. A business is a "machinery of people" and needs periodic tune-ups and reprogramming to go in vaguely the right direction.
In a lot of ways what it all comes down to is one of my personal favorite phrases, "fix ordinary things." Most of the time, we don't. We have a habit of putting off fixing all sorts of little things in our lives, even if our intentions are good, so of course we're caught by surprise by the disasters.
"In the time that it takes a sophisticated attacker to find a hole in Azure that will cause an hour of disruption across 1% of VMs, that same attacker could probably completely take down ten unicorns for a much longer period of time. And yet, these attackers are hyper focused on the most hardened targets. Why is that?"
I know a bit about the meltdown/spectre bugs and that seemingly was the case there: essentially a software hack to get more performance out of literally the same hardware. That was done to increase performance, but of course there were unintended consequences that nobody foresaw or cared to look for. It's almost obvious looking with hindsight - no free lunch etc.
So I wouldn't be surprised if there was a processor bug or two around that time that nobody got to the bottom of.
On the other, have a look at the errata sheets for older Intel CPU's: http://datasheets.chipdb.org/Intel/x86/386/specupdt/27287403...
BTW on the same topic, GPU drivers have many bugs, webrender maintain a wiki of bugs that affect them. Vulkan driver might have less bug as they seems smaller.
Intel FPU bugs from the 80's/90's. SPARC e-cache data parity errors (cost cutting) in the 90's/2000's. No thermal protections on AMD CPU's (Athlons?) in the 2000's to cut costs.
It had other peculiarities, too, as described at https://en.wikipedia.org/wiki/MOS_Technology_6502#Bugs_and_q....
When you have 3218 transistors, you don't make perfect features. The same thing happens when you have a very limited total instruction count to implement software.
Those FPU bugs weren’t due to design complexity - the former was presumably a mask bug, and the latter is “maths is hard”.
There was an errata for some of the arm thumb2 cpu designs that led to incorrect branching when a jump instruction spanned a page boundary, which is the only cpu bug I ever encountered.
Either way, they're CPU bugs.
For pentium FPU, but I was referring to https://en.m.wikipedia.org/wiki/Pentium_FDIV_bug
Oh, The one I was thinking of may have been FDIV rather than fsqrt. I mean the basic problem was the lookup table for the first NR guess was zero’d in a bunch of places and so the required number of NR iterations was incorrect and so sadness ensued.
But my point was those bugs weren’t due to complexity.
I think things like the f00f bug that was mentioned in another reply better fall into the “complexity is hard” area. The comment I was replying to was that it was complexity driven bugs, and I was trying to say that a number of the bugs we see aren’t in particularly complicated portions of the cpu - seriously the FPU bugs were all in some of the most sane portions of the CPU, vs f00f, spectre, etc which are a somewhat direct result of complex interactions of different parts of the cpu.
> To use PolyGerrit, please enable JavaScript in your browser settings, and then refresh this page.
Applying this fix to all other functions would certainly bloat the binary due to unnecessary padding and likely reduce performance for all, since the shipped binary is same for everyone.