Earlier quoted context omitted.
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.
> It affects code generated by the OCaml native compiler Possibly, but that was not the issue here. It's clear from your own link that the crashes were due to C code in the OCaml runtime (used by the compiler itself), which is written in C and was compiled with GCC at -O2. See https://caml.inria.fr/mantis/view.php?id=7452#c17129
Intel Skylake/Kaby Lake processors: broken hyper-threading
251–260 of 278 posts
Re: Intel Skylake/Kaby Lake processors: broken hyper-threading
#252Earlier quoted context omitted.
Then use a proof methodology that doesn't require exhaustive enumeration. You may as well have said "then you use a magical tool that doesn't exist". Strings also occupy a "large state space", but this obviously doesn't prevent us from doing formal verification on functions over strings. What is your reason to think this is 'obviously' the case?
> You may as well have said "then you use a magical tool that doesn't exist". Ok, so what this tells me is that you're not aware of what modern verification techniques look like. There's not really any one resource I can point you to, but take a look at these links. I've used these or similar technologies personally, but there are others I haven't used. https://en.m.wikipedia.org/wiki/Intuitionistic_type_theory https…
Ok, so what this tells me is that you're not aware of what
modern verification techniques look like.
Well, techniques are not tools. I am asserting that it is quite probable that no practically useful tool exists to non-exhaustively verify the state space laydn wants to cover.Notwithstanding your example that it's possible to non-exhaustively verify some functions on strings. There is a quite some distance between that to verifying just any function.
Because I've done this,
Sure, but how does that make it obvious to laydn that his state space is coverable? And what makes it so obvious to you that his state space is coverable? After all, the 'largeness' can have different sources, including those that make non-exhaustive methods infeasible.I think this may be an example of the disconnect between research and the industry. Researchers say things are solved when they have shown something is possible and published about it. They feel it's then up to the industry to extrapolate, while research moves on to exciting new and greener pastures. Meanwhile the industry thinks the results are too meager, thinks the extrapolation involves a lot of technical difficulties and generally is not willing to spend enough money on what they cannot see as anything but a longshot.
If you do any model checking at all, with tools like SPIN or TLA+, you are already in the state-of-the-art minority in industry.
Re: Intel Skylake/Kaby Lake processors: broken hyper-threading
#253Earlier quoted context omitted.
A few past lives ago, I used to work on the AIX kernel at IBM. I once spent a few weeks poring through trace data trying to investigate a very mysterious cache-aligned memory corruption induced by a memory stress test. Our trace data was quite comprehensive, and is always turned on due to its very low overhead. It was concerning enough (and took me long enough) that it eventually sucked in the rest of my team to aid…
Did you by chance see the paper a year back or so outlining that memory errors are more likely to occur near page boundaries? The author's premise was that a lot of 'cosmic rays' are just manufacturing flaws.
Re: Intel Skylake/Kaby Lake processors: broken hyper-threading
#254Earlier quoted context omitted.
In my limited experience, their root cause analyses are really impressive as well with lots of internal attention and resources. I'm not allowed to talk about any Intel issues, but we reported a very strange issue to Nvidia, sent a couple of dozen cards back and six months later got a truly fascinating report back we with hundreds of pages of compute test result tables and electron microscope images and chemistry lab…
Here's a video of a tour of Nvidia's lab: https://www.youtube.com/watch?v=pRz_CG3DZb4
Re: Intel Skylake/Kaby Lake processors: broken hyper-threading
#255The 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…
[1]Simultanious MultiThreading, which is marketed by Intel under the name Hyperthreading when using two threads.
Re: Intel Skylake/Kaby Lake processors: broken hyper-threading
#256Earlier quoted context omitted.
Hmmm... on that note, if the universe is a simulation, then a bug in that could have some interesting ramifications. "Don't use the bookshelf over there, physics is broken on that shiny spot." :D
> Hmmm... on that note, if the universe is a simulation, then a bug in that could have some interesting ramifications. > "Don't use the bookshelf over there, physics is broken on that shiny spot." :D You know "The Animatrix - Beyond"?
https://en.wikipedia.org/wiki/The_Animatrix#.22Beyond.22
Seems like the same kind of concept. :)
Re: Intel Skylake/Kaby Lake processors: broken hyper-threading
#257I wonder if a microcode update would solve some of the various issues I have in Windows.
Re: Intel Skylake/Kaby Lake processors: broken hyper-threading
#258Re: Intel Skylake/Kaby Lake processors: broken hyper-threading
#259Earlier quoted context omitted.
Did you by chance see the paper a year back or so outlining that memory errors are more likely to occur near page boundaries? The author's premise was that a lot of 'cosmic rays' are just manufacturing flaws.
Shouldn't ECC offer a second form of benchmark on this? If you see transient, cosmic-ray looking errors in ECC, presumably that's much stronger evidence of a hardware bug. Of course, I've also heard it claimed that ECC design and manufacture are held to a higher standard that might hide the issue.
Re: Intel Skylake/Kaby Lake processors: broken hyper-threading
#260Earlier quoted context omitted.
you mean i3 and i7. despite what cpuinfo tells you, no HT in i5. and my previous comment was ironic :)
But if you don't have HT in your i7, you basically have an i5 that you paid more than you needed for. Or has that changed? At one point, i7 was full-featured, i5 was an i7 with HT disabled, and i3 was i7 with HT intact but smaller caches. Is that different with Skylake/Kabylake? and my previous comment was ironic :) Ack - sorry. I must be irony-impaired. That's why I don't post very often. :-)