91–100 of 278 posts
Earlier 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.
IIRC wasn't there some blog posts about how intel has cut their verification/QA drastically since 2010? is this the result?
If Intel used marketing names that were more closely related to technical reality, then when something like this happens they wouldn't have so many customers finding themselves in the "maybe I'm affected by this horrid bug" box.
Earlier quoted context omitted.
Because futher down the stack, more reliable a tech has to be. Otherwise good luck debugging. Also agree with heisenbit.
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
Earlier quoted context omitted.
>Rule of thumb: On a desktop, if you have an i5 you do not have Hyperthreading. All i3s and i7s do have Hyperthreading, as do new Kaby Lake Pentiums (G4560, 4600, 4620). Hmm...either this statement is wrong or this desktop /proc/cpinfo is wrong: $ grep -E 'model|stepping|cpu cores' /proc/cpuinfo | sort -u cpu cores : 4 model : 94 model name : Intel(R) Core(TM) i5-6600 CPU @ 3.30GHz stepping : 3 $ grep -q '^flags.*[[:…
Hmmm, checking for "ht" seems to be giving weird info. On a i5-750 here (few years old), running Fedora 25: $ grep '^flags.*[[:space:]]ht[[:space:]]' /proc/cpuinfo flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni dtes64 monitor…
$ sudo dmidecode -t processor | grep -E 'Flags:|HTT|Status|Count'
Flags:
HTT (Multi-threading)
Status: Populated, Enabled
Core Count: 4
Thread Count: 4In 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…
It depends on what resources your code uses on-chip. If all threads are contending on the same resources, then you won't see a speedup; if they're using different resources, hyperthreading can increase throughput significantly. I've seen hyperthreading give me the equivalent of 50% of another CPU, particularly when I'm running multiple CPU-bound processes concurrently (so they're not executing the same code at the sa…
So if I understand correctly, some affected processors can be fixed by a microcode update, but there are some which cannot be fixed at all? Also the advisory seems to imply that the OCaml compiler uses gcc for code generation, which it does not -- it generates assembly directly, only using gcc as a front end to the linker.
It sounds like they can all be fixed by disabling hyperthreading.
mitigated
Earlier quoted context omitted.
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?
There are hardware bugs that are impossible to fix in microcode. What then?
Earlier 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…
Earlier quoted context omitted.
I wonder if there's a CPU out there that doesn't have bugs.
stop playing lawyer ball. i'm talking about the bugs that require turning off core functionality (such as hyperthreading) and/or that lead to system halts / corrupted data. yes it happens, but software bugs happen every day where as if your system blue screened every day you know dang well you'd be on the phone with the hardware vendor for a refund / new system.
Well, since hundreds of millions of people use Skylake/Kaby Lake CPUs for 2 years now, and only now we learn about this, obviously this is not of the "system blue screens every day" variety but a very rare bug.