Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

suspected bug: different results on x86 vs apple arm #2360

Closed
faddat opened this issue Jan 12, 2025 · 6 comments
Closed

suspected bug: different results on x86 vs apple arm #2360

faddat opened this issue Jan 12, 2025 · 6 comments
Labels
question Further information is requested

Comments

@faddat
Copy link

faddat commented Jan 12, 2025

This is the same floating point math test. The only difference is that it is being run on an ubuntu instance and on an M1.

Ubuntu fails because I used the result from my m1.

My understanding is that the output should be exactly the same, regardless of platform. Is that correct?

@ncruces
Copy link
Collaborator

ncruces commented Jan 12, 2025

Do you have source for the Wasm? Also, even if you don't have source for the Wasm, some minimal Go code to load the blob and show the difference would be helpful (obviously, the larger the blob, the worst that is).

A repo (or a gist) with a MCVE is always helpful.

Also, how was the Wasm compiled? Does it use SIMD? Is it possible the difference is in SIMD code?

In terms of assurances of the output being equal, I'm reasonably sure it should be equal, if it's using IEEE 754 floats. I'm less sure if it is using SIMD.

@anuraaga
Copy link
Contributor

anuraaga commented Jan 13, 2025

Also one thing to keep in mind is NaN isn't deterministic in Wasm.

https://github.com/WebAssembly/design/blob/main/Nondeterminism.md

Not sure but found that perhaps it is being used in the test case. Would be good to confirm it (though I would be surprised if Wasmer handled them more deterministically than Wazero).

https://github.com/CosmWasm/cosmwasm/blob/main/contracts/floaty/src/floats.rs#L27
https://github.com/CosmWasm/cosmwasm/blob/main/contracts/floaty/src/instructions.rs#L381
https://github.com/CosmWasm/wasmvm/blob/0b829226597bdbab9a2278c6a457ba452fb1b8a7/internal/api/lib_test.go#L1409

If NaN is indeed an issue, one approach could be to check the result IsNan and replace it with a constant NaN representation within the unit test.

@ncruces ncruces added the question Further information is requested label Jan 13, 2025
@ncruces
Copy link
Collaborator

ncruces commented Jan 15, 2025

@faddat if this is indeed an issue, it's something we'd want to fix. But we need more info/help.

@mathetake
Copy link
Member

yep, floating point is non deterministic and it's clearly documented in the spec (and each CPU has different behavior as it's undefined!) - unless you give us the real repro which doesn't involve NaN or Inf, i am closing

@faddat
Copy link
Author

faddat commented Jan 17, 2025

Ok, thank you all for your feedback!

I have been afk for a few days, and I'll poke around and come back.

@ncruces
Copy link
Collaborator

ncruces commented Jan 17, 2025

#2365 should not change anything, unless (again) there is a NaN (which is non-deterministic), or some SIMD that is allowed to have reduced precision, or of course, some other form of non-determinism (a clock, whatever).

If you have a discrepancy to report, between interpreter and compiler or across platforms, please do so. But it should be (as much as possible) a reduced test case, which is not supposed to be non-deterministic or unspecified to begin with.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

4 participants