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

ok      math/rand       331.167s

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. :)

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

On Fri, Feb 6, 2015 at 8:34 AM, Minux Ma notifications@github.com 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).

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 dave@cheney.net wrote:

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

On Fri, Feb 6, 2015 at 8:34 AM, Minux Ma notifications@github.com 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).

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
}

@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?

@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

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

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