Encoding result differs on x64 Intel/AMD platforms about opus HOT 3 CLOSED

I'm not sure the difference would even rise above measurement noise on any platform that can support x64, and I doubt it would ever be meaningful, it's so quick already. Most likely the "approximate" part of those instructions was just not noticed, since they're identical in x86 mode. (The RCPPS is outside the loop, so swapping it wouldn't even exist on a profile anyway.)

from opus.

If you want completely deterministic, you probably better stick to fixed point -- and even then I'm not 100% sure. With floating-point every compiler version, compile flag, build option, ... will change the result. Even if you consider a particular binary, there are other CPU-dependent bits of code that will change the results. For example, if the C code computes (a+b)+c and SSE computes a+(b+c), then the results may be different. Similarly, I believe the same a+b*c can give a different result depending on whether it's computed using mul and add, or using a fused multiply-add.

from opus.

Thank you for the quick replies!

Indeed using fixed point might be the safest way to go, but I was worried about the performance and quality impact as suggested in the README.

However, our use case really focus on a single DLL, which is compiled once, and runs on both platforms. So from what I understand, the resulting Opus may only vary based on runtime CPU feature detection (using CPUID), and from the "approximate" instructions that I mentioned above (I found those here, but the list might not be exhaustive).

On our CPUs, the SSE/AVX/FMA/... feature set seems equivalent on AMD and Intel, so we are only left with the approx-instructions causing trouble.

So yeah... Our use case might be a bit specific, and not worth the macro 😄

Anyway, thanks for the insights!

from opus.