Closed amitsadaphule closed 2 years ago
Hello, I am Blathers. I am here to help you get the issue triaged.
Hoot - a bug! Though bugs are the bane of my existence, rest assured the wretched thing will get the best of care here.
I have CC'd a few people who may be able to assist you:
If we have not gotten back to your issue within a few business days, you can try the following:
:owl: Hoot! I am a Blathers, a bot for CockroachDB. My owner is otan.
cc @cockroachdb/bulk-io
@amitsadaphule this is the result of a different floating-point behavior on PPC.
As explained in #72227, CockroachDB's team does not support alternative build platforms, so we're likely not going to work actively to resolve this particular problem. However, on the other hand we have many users that report that cockroachDB works on their platform, even if not officially supported.
Note that the difference in behavior wrt floating-point computations means that SQL queries are likely to return slightly differnt results than on other platforms. However, from experience the difference is often very small and depending on the application might be negligible.
Also, in the future please do not file common issues for multiple go packages. We would prefer different issues filed for different areas. Thank you.
Thanks @knz for your response again and point taken.
Just a quick confirmation/clarification on your statement above "this is the result of a different floating-point behavior on PPC."
I saw probably similar references at a couple of additional places today, basically https://github.com/gohugoio/hugo/issues/6387#issuecomment-538559712 https://github.com/disintegration/gift/issues/20#issuecomment-524551797
which essentially say that The Go compiler now implements a fused multiply and add (FMA) instruction on some architectures, which leads to floating-point rounding differences compared to amd64. is this what you are pointing to as well?
I wasn't aware about the FMA behavior in the go compiler, but yet it could contribute to the situation as well.
Note that even without FMA, there are subtle differences in the ordering of FP operations inside the micro-architecture that can cause rounding differences.
The geo failures are fixed by https://github.com/cockroachdb/cockroach/pull/81734.
The geogfn and geomfn failures are fixed by: https://github.com/cockroachdb/cockroach/pull/81894 https://github.com/cockroachdb/cockroach/pull/82250
One of the geoindex failure is fixed by https://github.com/cockroachdb/cockroach/pull/82456.
Following failures are not reproducible anymore:
Hello @otan, How are the fixes in vendored code handled? I've a solution for test failures in pkg/geo/geomfn. It'll be submitted to the original source repository. However, it'll take some time to get merged and then be synchronized in vendored repo. Is it allowed to commit changes in vendored repo directly?
Thank you, Prashant
if you let me know which change i can let you know further
I need to force floating-point type conversion in twpayne/go-geom/xy/lineintersector/nonrobust_line_intersector.go to avoid FMA on ppc64le.
The go-geom v1.4.2 has the required fix in nonrobust_line_intersector.go. The PR #214 resolves geomfn/TestShortestLineString test failure on ppc64le. The PR #213 fixes test failures in go-geom.
gotcha, sorry just came back from holiday. updating vendor here: https://github.com/cockroachdb/cockroach/pull/86126
Describe the problem
I built the cockroachdb v20.2.17 on ppc64le and when I executed the test suite, I found that there were test failures for the following packages:
When I analysed the logs FP-precision-failures.zip, I found that the failing tests were due to floating point precision issues. A sample log of test failure for
geogfn
package pasted below (Please refer full package test logs in attached zip for more details):To Reproduce
Here are the steps to reproduce the issue:
Environment:
CockroachDB [v20.2.17] Architecture and OS: [ppc64le/RHEL/UBI 8.4] Go: [1.13.5] Node: [12.18.2]
Any pointers to resolve the failures would be of great help.
Jira issue: CRDB-11048