math/rand: rand tests take a long time to run on arm5

[davecheney]

The math/rand tests take a very long time to run on platforms without an FPU. We've fixed the run time of this package a few times, however this package may have regressed while the arm5 builder was offline

linux-arm-arm5:

ok      math/rand   183.211s

[davecheney]

Actually it's very slow on all arm platforms
linux-arm-panda:

ok      math/rand       331.167s

[josharian]

The regression is pretty extreme, actually: ~30x slower. Numbers from an RPi.

1.4:

=== RUN TestStandardNormalValues
--- PASS: TestStandardNormalValues (0.09s)
=== RUN TestNonStandardNormalValues
--- PASS: TestNonStandardNormalValues (11.36s)
=== RUN TestStandardExponentialValues
--- PASS: TestStandardExponentialValues (0.08s)
=== RUN TestNonStandardExponentialValues
--- PASS: TestNonStandardExponentialValues (0.71s)
=== RUN TestNormTables
--- PASS: TestNormTables (0.00s)
=== RUN TestExpTables
--- PASS: TestExpTables (0.00s)
=== RUN TestFloat32
--- PASS: TestFloat32 (12.31s)

tip

=== RUN TestStandardNormalValues
--- PASS: TestStandardNormalValues (2.51s)
=== RUN TestNonStandardNormalValues
--- PASS: TestNonStandardNormalValues (319.04s)
=== RUN TestStandardExponentialValues
--- PASS: TestStandardExponentialValues (2.55s)
=== RUN TestNonStandardExponentialValues
--- PASS: TestNonStandardExponentialValues (20.45s)
=== RUN TestNormTables
--- PASS: TestNormTables (0.09s)
=== RUN TestExpTables
--- PASS: TestExpTables (0.16s)
=== RUN TestFloat32
--- PASS: TestFloat32 (524.50s)

Running a quick CPU profile shows lots of the new time being spent in runtime.stepflt, called from runtime._System. The hottest address outside floating point routines is in runtime·systemstack.

Based on that, I wonder whether someone (GC?) is doing lots of floating point work where it wasn't before, and it's contending for the system stack in order to run floating point routines.

I'll start doing a bisection to find the relevant commit. It'll take a while. :)

[minux]

stepflt is the floating point emulation routine. Is your Go compiled with GOARM=5 somehow? If it is, that might explain the huge performance regression.

[minux]

oh, this issue is about the GOARM=5 case. Always running software FP on system stack is definitely one of the reasons for the performance regression.

[davecheney]

GOARM=6 and GOARM=7 are also horribly slow.

On Fri, Feb 6, 2015 at 8:34 AM, Minux Ma [email protected] wrote:

oh, this issue is about the GOARM=5 case.

Always running software FP on system stack is definitely one of the reasons
for the performance regression.

—
Reply to this email directly or view it on GitHub
#9732 (comment).

[davecheney]

I think that in the switch to cmd/dist written in Go, GOARM now always
ends up being set to 5, so all arm implementations are using softfloat

On Fri, Feb 6, 2015 at 8:34 AM, Dave Cheney [email protected] wrote:

GOARM=6 and GOARM=7 are also horribly slow.

On Fri, Feb 6, 2015 at 8:34 AM, Minux Ma [email protected] wrote:

oh, this issue is about the GOARM=5 case.

Always running software FP on system stack is definitely one of the
reasons
for the performance regression.

—
Reply to this email directly or view it on GitHub
#9732 (comment).

[davecheney]

Yes, xgetgoarm defaults to 5, and will not attempt vfp detection because

func xtryexecfunc(f func()) bool {
        // TODO(rsc): Implement.
        // The C cmd/dist used this to test whether certain assembly
        // sequences could be executed properly. It used signals and
        // timers and sigsetjmp, which is basically not possible in Go.
        // We probably have to invoke ourselves as a subprocess instead,
        // to contain the fault/timeout.
        return false
}

[josharian]

@davecheney yep. My bisection finally finished and pointed the finger at one of these commits:

20a10e7
ad6ee36
d369f97

Do you think that there is a separate math/rand regression, or should we just convert this issue to track fixing that TODO?

[davecheney]

@josharian i'll fix the vfp detection in cmd/dist/util.go (it turns out all the twiddling we did on the .s files was pointless, they aren't being called).

With GOARM detected properly, there is not issue with math/rand

panda(~/go/src) % go test -short math/rand
ok      math/rand       2.446s

[davecheney]

@josharian https://go-review.googlesource.com/#/c/3981

[gopherbot]

CL https://golang.org/cl/3973 mentions this issue.