Does this affect execution of Ocaml runtime, or only the Ocaml compiler?
It seems like everything that uses less than 64 instructions in a loop while using the AH, BH, CH or DH registers is affected.
Intel Skylake/Kaby Lake processors: broken hyper-threading
41–50 of 278 posts
Re: Intel Skylake/Kaby Lake processors: broken hyper-threading
#42Earlier 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?
In general, people expect hardware to be far more bug-free than all the software which depends on it. I'm disgusted enough at the current trend of continuously releasing half-baked software and "updating" it to fix some of the bugs (while introducing new bugs in the process); and yet it seems to be spreading to hardware too. From the perspective of formal verification, buggy hardware is like an incorrect axiom.
but Intel isn't allowed to have issues in their processors, even if they can fix them with a software (microcode) update?
They could've caught and fixed this one with some more testing, before actually releasing. Formal verification isn't necessarily going to help, if it's a statistical type of defect --- thus the concept of wafer yield, and why dies manufactured from the exact same masks can behave completely differently with respect to the clock speeds attainable and voltages required.
Re: Intel Skylake/Kaby Lake processors: broken hyper-threading
#43Earlier 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?
It's funny, since many of today's software bugs are due to the legacy of C, faults of which can often times be attributed to mimicking the behaviour CPU hardware too closely.
EDIT: My wording was poor, but what I meant was that it's not like hardware vendors do not make bugs happen due to deficiencies in their design, which are not only tolerated, but often reflected in software, which runs counter to OP saying that apparently hardware vendors are not allowed to have bugs, but the software ones are:
> 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
Re: Intel Skylake/Kaby Lake processors: broken hyper-threading
#44Does this affect execution of Ocaml runtime, or only the Ocaml compiler?
It affects code generated by the OCaml native compiler, which includes the OCaml compiler itself since it is written in OCaml. See also: https://caml.inria.fr/mantis/view.php?id=7452
It also affects code generated by GCC, but apparently GCC is less likely to generate code sequences which trigger the CPU bug.
Re: Intel Skylake/Kaby Lake processors: broken hyper-threading
#45The latest intel-microcode package from Ubuntu 16.04 does not fix the problem. I installed the same package from Ubuntu 17.10 [0] which fixes the problem. You can check your system with the script linked in the mailing list thread [1]. [0] https://packages.ubuntu.com/en/artful/amd64/intel-microcode/... [1] https://lists.debian.org/debian-devel/2017/06/msg00309.html
Launchpad bug report for this: https://bugs.launchpad.net/ubuntu/+source/intel-microcode/+b...
Re: Intel Skylake/Kaby Lake processors: broken hyper-threading
#46Well, at least Intel acknowledges, documents and finally fixes these CPU bugs (via microcode updates). AMD on the other hand doesn't even acknowledge an issue when multiple customers report problems. See this Ryzen bug: https://community.amd.com/thread/215773
>at least Intel acknowledges Not in this case. "Apparently, Intel had indeed found the issue, documented it (see below) and fixed it . There was no direct feedback to the OCaml people, so they only found about it later."
It was acknowledged, and documented in a errata bulletin, but not communicated back to the reporter. Assuming that it had not already been reported, discovered internally, or reported by another source. Seems more like sloppy followup on a bug report, which unfortunately happens in any large project.
Re: Intel Skylake/Kaby Lake processors: broken hyper-threading
#47So will this be affecting most Macbook Pros of the past few years? If so, there's a way to disable hyper-threading, but you need Xcode (Instruments). Open Instruments. Go to Preferences. Choose 'CPU'. Uncheck "Hardware Multi-Threading". Rebooting will reset it.
No. Even though Skylake came out in 2015, Apple used an older CPU (Haswell) until the October 2016 MacBook Pros.
Re: Intel Skylake/Kaby Lake processors: broken hyper-threading
#48In my experience with parallel code written in Haskell, hyper-threading offers only a very mild speedup, perhaps 10%. It is essentially an illusion, a logical convenience. (How long does it take to complete a parallel task on a dedicated machine? Four cores with hyper-threading off has nearly the performance of eight virtual cores with hyper-threading on.)
Many people have neither the interest nor the hardware access to overclock, and these processors have less overclocking headroom than earlier designs. Nevertheless, the hyper-threading hardware itself generates heat, restricting the overclocking range for given cpu cooling hardware. In this case, turning off hyper-threading pays for itself, because one can then overclock further, overtaking any advantage to hyper-threading.
Re: Intel Skylake/Kaby Lake processors: broken hyper-threading
#49Re: Intel Skylake/Kaby Lake processors: broken hyper-threading
#50Does Windows have a patch for this too? Or just disabling HT is the safest option?
Windows does have a microcode update driver, as you would expect, so it can fix this.
However, looking at the microcode update driver on an updated Windows 10 as of right now, I don't see a recent enough microcode version to fix it. The latest updates appear to be from 2015.