I found a bug in Intel Skylake processors

Post by justin66 » Mon, Jul 03, 2017, 4:25 PM UTC

piemonkey wrote: post #61

justin66 wrote: post #60

Earlier quoted context omitted.

I know nothing of OCaml culture or why the author is deemed worthy of having his name italicized, but the doctor comparison is upsetting. If the guy who wrote this: I was tired of this problem, didn't know how to report those things (Intel doesn't have a public issue tracker like the rest of us), and suspected it was a problem with the specific machines at SIOU (e.g. a batch of flaky chips that got put in the wrong s…

His name is italicized because he is the primary author of OCaml (and a plethora of other great tools, like CompCert, the first fully-verified compiler). Overall, an exceedingly competent and productive programmer and scientist. The doctor metaphor isn't perfect; what I was going for is, when you are seeking out an expert's advice and you ignore it, why do you go to see the expert in the first place?

Post by qb45 » Mon, Jul 03, 2017, 4:46 PM UTC

lmm wrote: post #20

zrth wrote: post #12

Earlier quoted context omitted.

Who can clarify? Google says: Qbvious - easily perceived or understood; clear, self-evident, or apparent.

The confusion is between "the assembly clang generates is the obviously correct assembly for this operation" (true) and "the obviously correct behaviour for a compiler is to generate the assembly that clang does" (disputable, as while the assembly GCC generates is less clear, there may be advantages to doing it that way in e.g. performance). "Clang does the obvious, correct thing." is ambiguous between these two mean…

  obvious, correct != obviously correct

Post by qb45 » Mon, Jul 03, 2017, 4:59 PM UTC

raverbashing wrote: post #48

userbinator wrote: post #46

Earlier quoted context omitted.

"smaller but not optimal" is not really true. It depends on what you're optimising for. In my experience, optimising for size overall, and then speed in the really performance-critical parts (with some expected expansion), gives the best results. Even the non-performance-critical code will have a noticeable effect if its larger size causes more cache misses. Making use of the "partial registers" (I see them more as s…

I don't disagree with you, but then use EAX, not AH (which would also produce a smaller code as you don't need to use a 64-bit constant) Optimizing for size is good, but what GCC did there made sense in the 32-bit days, but not that much today Some code snippets use AH/AL as 2 separate registers hence the processor might rename them to different internal registers. But then when reading EAX the processor needs to upd…

Post by aij » Mon, Jul 03, 2017, 5:00 PM UTC

raverbashing wrote: post #15

tom_mellior wrote: post #11

Earlier quoted context omitted.

Do you know for a fact that Clang's code is faster here, i.e., have you measured it on actual hardware? Armchair performance estimation about "the potential" for something is often wrong...

It might not, but the GCC code has a potential issue in how it does things https://stackoverflow.com/a/41574531 (curiously the question is about GCC not doing it, apparently not always)

Post by detaro » Mon, Jul 03, 2017, 5:14 PM UTC

qb45 wrote: post #69

tvgggghh wrote: post #67

Earlier quoted context omitted.

Err, that's on purpose? It's so you can tell your writes apart, which is helpful while debugging. They used to use, uh, more obvious patterns but the PC brigade called them on it so they settled on 0xcd.

Um, what was it? You can paste in decimal to avoid triggering the PC brigade ;)