Personal computing discussed
Moderators: renee, Flying Fox, morphine
Losergamer04 wrote:I find it highly unlikely that AMD took their sparse engineering dollars to modify silicon to cheat their way in an obscure benchmark that no one really uses. I think if they had done that they would have touted those numbers or intentionally leaked them prior to release.
morphine wrote:Disclaimer: personal, non-editor opinion.
For the sake of argument, let's assume there's some nefarious plot here. Why the heck would AMD bother working out a way to cheat at... CPU-Z? Talk about not shooting for the moon.
A bit of code that works in a certain way with Ryzen happened to be in CPU-Z. End of story.
DancinJack wrote:Come on chuck. This one is a bit too thin to call it "caught cheating."
chuckula wrote:DancinJack wrote:Come on chuck. This one is a bit too thin to call it "caught cheating."
I'm just applying the same standards to AMD that regularly get applied to AMD's competitors around here. If AMD is back to being some type of top-dog in the CPU/GPU world then they'll have to deal with the fallout of stuff like this just like anybody else will.
Chrispy_ wrote:I have been using CPU-Z/CPUID since my Socket A days 15 years ago and I wasn't even aware there was a benchmark. I thought it was just an overclock validation and test-bench stress tool.
So, I bother looking at the bench tab and see there is in fact a benchmark in there now. How long has that been there?
chuckula wrote:Well the CPU-Z benchmark was pretty much worthless before this update and if it's only using 16 year old SSE2 instructions from 2001 and couldn't even be bothered to use 6 year old AVX instructions from 2011, then it's at least consistently worthless.
End User wrote:Your own comment from that TR post:chuckula wrote:Well the CPU-Z benchmark was pretty much worthless before this update and if it's only using 16 year old SSE2 instructions from 2001 and couldn't even be bothered to use 6 year old AVX instructions from 2011, then it's at least consistently worthless.
Ordinarily, that kind of automatic optimization would be welcome, but upon further investigation, the CPU-Z team failed to replicate that behavior with Ryzen CPUs in real-world situations. Furthermore, the team says that due to the extreme unlikelihood of that specific sequence of instructions showing up in non-benchmark software, it felt it would be best to revise CPU-Z to reflect real-world results more accurately.
Ryu Connor wrote:While there's still a possibility that this happens to be a complete coincidence. There's also a possibility that some engineer did in fact make this tweak.
just brew it! wrote:The most likely scenario is that the benchmark was doing some calculations and throwing the results away (e.g. saving the results in machine registers and not storing them to RAM before overwriting them with something else). The CPU noticed the calculations were pointless, and skipped them. This is a perfectly valid thing to do, since it can speed up poorly coded applications (or applications compiled with less-than-optimal compilers), and does not affect the output of a program that actually does something useful. No nefarious intent required.
To avoid this sort of thing, benchmark code needs to use instruction sequences which resemble those which would be used in real-world applications, instead of sequences of instructions which are "unlikely to appear in non-benchmark software".
chuckula wrote:DancinJack wrote:Come on chuck. This one is a bit too thin to call it "caught cheating."
I'm just applying the same standards to AMD that regularly get applied to AMD's competitors around here. If AMD is back to being some type of top-dog in the CPU/GPU world then they'll have to deal with the fallout of stuff like this just like anybody else will.
just brew it! wrote:The most likely scenario is that the benchmark was doing some calculations and throwing the results away (e.g. saving the results in machine registers and not storing them to RAM before overwriting them with something else). The CPU noticed the calculations were pointless, and skipped them. This is a perfectly valid thing to do, since it can speed up poorly coded applications (or applications compiled with less-than-optimal compilers), and does not affect the output of a program that actually does something useful. No nefarious intent required.
To avoid this sort of thing, benchmark code needs to use instruction sequences which resemble those which would be used in real-world applications, instead of sequences of instructions which are "unlikely to appear in non-benchmark software".
Waco wrote:There's literally zero incentive for them to do so, and they run the risk of making particular code paths unstable if it really is a "cheat".