I.S.T. wrote:chuckula wrote: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.
It just really seems like you got an axe to grind and you're letting that cloud your judgment.
Kinda feels like AMD ran over his dog or something...
Unless there's a shred of evidence that this was anything more than an optimization to eliminate execution of redundant instructions, which tripped up a sloppily coded benchmark, there shouldn't be any "fallout" to deal with.
ptsant wrote:When I got my Ryzen 1700x, I ran my own assembly hand-coded benchmark from the 90s. <snip>
Comparing with Vishera, and especially the Phenom, I realized that the CPU was probably not even executing these instructions. It correctly deduced that I was rewriting the same thing and simply didn't to it. Now, I don't know how often this occurs in practice, because the code was, as I said, very artificial, but it seemed to be like a particularly nifty optimization. Not cheating.
It seems fairly likely that you encountered either the same, or a very similar scenario to what tripped up CPU-Z. I'd say this is pretty good evidence that RyZen is simply very good at spotting certain types of superfluous instruction sequences, and optimizing them out.
ptsant wrote:The way I see it, the CPU obtained the necessary result (the output). Executing all the instructions is not, in itself, a requirement.
Bingo.
The only downsides I can think of are:
1. Code which depends on timing loops may misbehave. In general timing loops are a bad idea anyway. Execution time of specific instruction sequences is already unpredictable enough on modern architectures (clock speeds vary widely due to power saving modes, and HT tosses another variable into the mix...) to be problematic. It's also inefficient, since that core could be off doing something useful on another thread instead of just looping.
2. Complex optimizations open up the possibility of introducing complex bugs. If the CPU gets confused into skipping instructions that actually matter, that's a problem.
3. Benchmark writers need to be more careful to avoid clearly redundant sequences of operations, and to ensure that results of calculations get "used" in a way that convinces any optimization logic that those calculations affect system state in a meaningful way.
ptsant wrote:It all comes down to (a) whether the final state of the system was the same (including memory, registers and flags) or not for having skipped the instructions and (b) whether the behavior is documented. You really can't say it's cheating if the Ryzen system achieves the same output as an Intel system, no matter how it got there. I'd rather say the benchmark needs to be modified to properly account for a new type of optimization. Happens all the time.
I'd even argue that it doesn't need to be documented, other than a blanket statement to the effect that "execution of instruction sequences which have no net effect on state may be skipped".