Earlier quoted context omitted.
Still seems to be doing better than "turn off half of your processor, sorry no fix just buy a new one".
Actually TFA mentions there's already a fix.
For some models.
Intel Skylake/Kaby Lake processors: broken hyper-threading
111–120 of 278 posts
Re: Intel Skylake/Kaby Lake processors: broken hyper-threading
#112Earlier quoted context omitted.
CPU manufacturers do do huge amounts of testing, and Intel does formal verification of some functional units. The reliability is far better than most software, in part because making a new release costs billions.
i am more willing to accept software having bugs / failing. i have 0 tolerance for hardware to have bugs
How much more would you pay, or how much of a speed penalty would you take, for bug-free CPUs?
Re: Intel Skylake/Kaby Lake processors: broken hyper-threading
#113Earlier quoted context omitted.
That's absolutely true. When it comes to CPU/memory, skilled software engineers always think, "it must be my bug, it always is". So in that super rare case of actually running into a CPU defect, it's a mindfuck, it'll drive you crazy. You'll be looking for the flaw in your algorithm which makes it fail once a week under production load. But you just can't find it, it makes no sense ... (When it comes to drivers for n…
Similarly: Kernel bugs! Once upon a time I spend a good week trying to reproduce a rare crash one of our users saw ever so often (just enough to get our attention, but not enough to get a repro case). Stack traces made no sense and just in general the whole crash made no sense the more I looked at it. Turns out it was a bug in XNUs pthread subsystem, a part where I would have never looked if it weren‘t for desperatio…
Or at least should have been long since spotted thanks to use and abuse.
Re: Intel Skylake/Kaby Lake processors: broken hyper-threading
#114The problem description is short and scary: Problem: Under complex micro-architectural conditions, short loops of less than 64 instructions that use AH, BH, CH or DH registers as well as their corresponding wider register (e.g. RAX, EAX or AX for AH) may cause unpredictable system behavior. This can only happen when both logical processors on the same physical processor are active. I wonder how many users have experi…
> short loops of less than 64 instructions that use AH, BH, CH or DH registers as well as their corresponding wider register (e.g. RAX, EAX or AX for AH) This is yet another of the many places where the complexity of the x86 ISA shows up and makes its hardware implementations more complicated: the x86 ISA has instructions which can modify the second -lowest byte of a register, while keeping the rest of the rest of th…
This is an amazing analysis, and seems entirely likely to be right to me. Thanks for writing it up.
Re: Intel Skylake/Kaby Lake processors: broken hyper-threading
#115Earlier quoted context omitted.
CPU manufacturers do do huge amounts of testing, and Intel does formal verification of some functional units. The reliability is far better than most software, in part because making a new release costs billions.
releasing cpu micro code to work around bugs is very cheap.
But that doesn't mean you necessarily get to keep the affected feature - the only 'work-around' might be to disable it. Consider TSX on Haswell and Broadwell, where Intel had to disable the whole feature because of a bug. And of course there was the 486 FP bug which couldn't be fixed by any kind of microcode update.
If Intel had to completely disable hyperthreading in Skylake and Kabylake that would make the premium anyone paid for i5 vs i7 worthless.
Re: Intel Skylake/Kaby Lake processors: broken hyper-threading
#116Earlier quoted context omitted.
This seems like precisely the sort of thing that a competent manufacturer should rule out formally. Formal verification of individual FUs isn't exactly ambitious... I think we're getting to levels of complexity where the process Intel uses, with lots of different QA and testing teams doing their best to look for bugs, just isn't going to cut it. We need formally verified models transformed step-by-verified-step all t…
So it's okay for software to have bugs that get fixed (I think everybody here acknowledges that software will always have bugs), but Intel isn't allowed to have issues in their processors, even if they can fix them with a software (microcode) update?
Well, if a software bug leads to data corruption it is not really "allowed" as well. It is quite amazing that there are not more bugs like this. Intel spends an insane amount of money on very large teams of very smart people to work on these insanely complicated systems.
I don't think this is sustainable, and I think that massive arrays of relatively simple processors. First, we will need a culture shift that learns programmers to program concurrent programs from the start, and this will take a lot of time (because technology moves a lot faster than culture).
Re: Intel Skylake/Kaby Lake processors: broken hyper-threading
#117Earlier quoted context omitted.
CPU manufacturers do do huge amounts of testing, and Intel does formal verification of some functional units. The reliability is far better than most software, in part because making a new release costs billions.
That's absolutely true. When it comes to CPU/memory, skilled software engineers always think, "it must be my bug, it always is". So in that super rare case of actually running into a CPU defect, it's a mindfuck, it'll drive you crazy. You'll be looking for the flaw in your algorithm which makes it fail once a week under production load. But you just can't find it, it makes no sense ... (When it comes to drivers for n…
You have some lovely stories online about these things. Like the guy tracking down a stuck bit in RAM.
Or on the network level, a VPN that failed only when traversing one possible route between company offices.
Re: Intel Skylake/Kaby Lake processors: broken hyper-threading
#118Earlier quoted context omitted.
releasing cpu micro code to work around bugs is very cheap.
But that doesn't mean you necessarily get to keep the affected feature - the only 'work-around' might be to disable it. Consider TSX on Haswell and Broadwell, where Intel had to disable the whole feature because of a bug. And of course there was the 486 FP bug which couldn't be fixed by any kind of microcode update. If Intel had to completely disable hyperthreading in Skylake and Kabylake that would make the premium…
you mean i3 and i7.
despite what cpuinfo tells you, no HT in i5.
and my previous comment was ironic :)
Re: Intel Skylake/Kaby Lake processors: broken hyper-threading
#119Holy cow. Definitely feel like I dodged a bullet by building an AMD/Ryzen system this time around - which had it's own set of issues (but seem to be more or less ironed out now).
I don't think Ryzen has had any more or less bugs than the recent Intel generation. They are at least on the same order of magnitude. Ryzen is great, I might buy one next, but it is not to "doge bullets".
doge? :D
Re: Intel Skylake/Kaby Lake processors: broken hyper-threading
#120Earlier quoted context omitted.
Still seems to be doing better than "turn off half of your processor, sorry no fix just buy a new one".
Hyperthreads are just that - threads. It won't be 50 % slower with HT disabled.
Depends on the workload… If all the stuff you run uses different parts of the pipeline, HT helps a lot