Can someone with compiler or spec expertise confirm that this means
that the x/image/vector package should not test for identical results,
only for close results within some tolerance band? Even pure Go code
can produce different values on different GOARCHes, or on different
compilers for the same GOARCH, right?
...
As an aside, if an expression "x*y" has type T, I'm a little surprised
that "x*y" and "T(x*y)" can have different semantics, and the
conversion from T to T is not a no-op, so code simplifiers can't
always remove the conversion as redundant, but I guess that boat has
sailed.
The golang.org/x/image/vector package contains a vector graphics
rasterizer, heavy on floating point computation.
It contains tests that ensure that the package's output is the same on
all GOARCHes. Some GOARCH-dependent code paths are asm-accelerated,
some are not. For example, in the amd64 assembly (using SIMD), we are
careful to set the MXCSR rounding bits so that the output is
identical, not just close.
Those tests haven't changed for about a year, but
https://golang.org/issue/21460, filed a couple of weeks ago, notes
that the tests fail on GOARCH=s390x and on GOARCH=ppc64le. The
speculation is that this is due to the new fused multiply add (FMA)
support on these architectures.
The Go spec (https://golang.org/ref/spec#Floating_point_operators)
says that "An implementation may combine multiple floating-point
operations into a single fused operation, possibly across statements,
and produce a result that differs from the value obtained by executing
and rounding the instructions individually."
Can someone with compiler or spec expertise confirm that this means
that the x/image/vector package should not test for identical results,
only for close results within some tolerance band? Even pure Go code
can produce different values on different GOARCHes, or on different
compilers for the same GOARCH, right?
What is the status of FMA support across the GOARCHes? I haven't been
following it closely, and I'm not very familiar with FMA.
Specifically, I would like to keep testing that the asm and no-asm
floating point computations produce identical (not just close) results
on amd64, even if I can't test that across all GOARCHes. Does (pure
Go, no asm) amd64 do FMA now?
If not, is it likely to do FMA in the
future?
Can FMA versus non-FMA produce different values on amd64?
Or is the solution to replace "x*y" with "float64(x*y)" throughout the
x/image/vector code, to explicitly disallow FMA, as per the examples
in the Go spec section linked to above?
As an aside, if an expression "x*y" has type T, I'm a little surprised
that "x*y" and "T(x*y)" can have different semantics, and the
conversion from T to T is not a no-op, so code simplifiers can't
always remove the conversion as redundant, but I guess that boat has
sailed.
--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
As an aside, if an expression "x*y" has type T, I'm a little surprised
that "x*y" and "T(x*y)" can have different semantics, and the
conversion from T to T is not a no-op, so code simplifiers can't
always remove the conversion as redundant, but I guess that boat has
sailed.
Sorry to revive an old thread, but now that math.FMA has been merged into tip for 1.14, could the float rasterizer use that function instead? The caveat is that math.FMA takes in float64 values, which seems to be okay given the already existent use of float64 in raster_floating.go.func fma(x, y, z float32) float32 {return float32(math.FMA(float64(x), float64(y), float64(z)))}
--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/6f5be9ae-4792-4e49-931a-3350f6b23c1a%40googlegroups.com.
Why is fma useful here? I think you could get all the no-intermediate-rounding behavior just converting to float64 and back.(Can a float64 hold all possible results of a float32*float32? I think so, but I'm not entirely sure.)
--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/673d9494-8534-44c7-954b-0caa0e96bece%40googlegroups.com.
What case is that?
--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/34f504e6-1469-41dd-b56a-3a89efd16f4d%40googlegroups.com.
I'm confused. This program reports no errors:
--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/ea3b0b5c-5c24-4400-b478-f6145b70de85%40googlegroups.com.
So I guess my question is: where are you getting the "want" fields in this test?
So does the difference come down to the fact that g round to a float64 (after the + operation), then round again to a float32, and that's not the same as a hypothetical math.FMA32 which does both of those roundings in a single step?
--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/331f5825-d229-4d4f-887f-a3bbc01279a3%40googlegroups.com.