4 ms·

Yeah, I'm super curious here. It's a very bold claim. It's possible that they've got some kind of data race/memory barrier/other threading issue that's more lik

Yeah, I'm super curious here. It's a very bold claim. It's possible that they've got some kind of data race/memory barrier/other threading issue that's more likely to get tickled by Intel processors than AMD processors. Hell, it could even be a compiler bug that generates incorrect assembly that trips more often on Intel processors.

eqvinox 2y ago
There is no such thing as "incorrect assembly", modern CPUs don't have undefined instructions like the 6502 did. Either it gets executed deterministically, or you get an #UD exception.
- cpgxiii 2y ago
  That's not quite true, though. While there are no singular undefined instructions, there are sequences of instructions that can result in undesired/undefined behavior. Read through the published errata for modern CPUs, there will be a large number of combinations of instructions/actions that should be avoided entirely or modified to avoid misbehavior.
  - eqvinox 2y ago
    > Read through the published errata for modern CPUs I totally agree, and this entire HN post is about the fact that these Intel CPUs probably have some yet-undiscovered erratas. Best theory at this point is that it's power/thermal related though. > there will be a large number of combinations of instructions/actions that should be avoided As a matter of fact, reading those erratas is part of my job, and no, it is very rare for such erratas to have the effect you're implying. Rare enough that this issue that is seen here would already have been matched against an errata. I don't see anything in Intel's current errata — other than their in-progress responses to these reports — that could explain this. Here's the errata sheet for 13th/14th gen: https://edc.intel.com/content/www/us/en/design/products/platforms/details/raptor-lake-s/13th-generation-core-processor-specification-update/summary-tables-of-changes/ https://edc.intel.com/content/www/us/en/design/products/plat... … do you see anything?
- tonyarkles 2y ago
  If you want to be pedantic, how about "incorrectly translating code into assembly such that two statements that should be separated by a sequence point in the C memory model can interfere with each other, but the implementations before this generation of Intel processor wouldn't reorder microcode execution such that it was actually a problem in practice".
  - eqvinox 2y ago
    > statements that should be separated by a sequence point in the C memory model can interfere with each other, That also doesn't exist on x86 since it is a TSO platform. The other thing is that even in the extremely unlikely case that some new behavior in 13th/14th gen Intel CPUs is exposing a bug in either code or compiler that has just been lurking there for who knows long, and doesn't affect any other CPU at all… … with the way the world works, it'd still be a CPU bug, even if there was a document somewhere that says the CPU is right. x86 is shoved down the compatibility road so far, it just doesn't matter what some paper says if you break compat. (For user space at least, kernel is not quite there.)

eqvinox 2y ago

There is no such thing as "incorrect assembly", modern CPUs don't have undefined instructions like the 6502 did. Either it gets executed deterministically, or you get an #UD exception.

cpgxiii 2y ago
That's not quite true, though. While there are no singular undefined instructions, there are sequences of instructions that can result in undesired/undefined behavior. Read through the published errata for modern CPUs, there will be a large number of combinations of instructions/actions that should be avoided entirely or modified to avoid misbehavior.
- eqvinox 2y ago
  > Read through the published errata for modern CPUs I totally agree, and this entire HN post is about the fact that these Intel CPUs probably have some yet-undiscovered erratas. Best theory at this point is that it's power/thermal related though. > there will be a large number of combinations of instructions/actions that should be avoided As a matter of fact, reading those erratas is part of my job, and no, it is very rare for such erratas to have the effect you're implying. Rare enough that this issue that is seen here would already have been matched against an errata. I don't see anything in Intel's current errata — other than their in-progress responses to these reports — that could explain this. Here's the errata sheet for 13th/14th gen: https://edc.intel.com/content/www/us/en/design/products/platforms/details/raptor-lake-s/13th-generation-core-processor-specification-update/summary-tables-of-changes/ https://edc.intel.com/content/www/us/en/design/products/plat... … do you see anything?
tonyarkles 2y ago
If you want to be pedantic, how about "incorrectly translating code into assembly such that two statements that should be separated by a sequence point in the C memory model can interfere with each other, but the implementations before this generation of Intel processor wouldn't reorder microcode execution such that it was actually a problem in practice".
- eqvinox 2y ago
  > statements that should be separated by a sequence point in the C memory model can interfere with each other, That also doesn't exist on x86 since it is a TSO platform. The other thing is that even in the extremely unlikely case that some new behavior in 13th/14th gen Intel CPUs is exposing a bug in either code or compiler that has just been lurking there for who knows long, and doesn't affect any other CPU at all… … with the way the world works, it'd still be a CPU bug, even if there was a document somewhere that says the CPU is right. x86 is shoved down the compatibility road so far, it just doesn't matter what some paper says if you break compat. (For user space at least, kernel is not quite there.)