math/rand: 172 second tests on arm5 #10749
Comments
|
Related #10571 |
|
Related to #9732? |
|
Indeed, this is an linux-arm-arm5 build underway. |
bradfitz
changed the title
|
The software floating point emulation is terribly slow.
As GOARM=5 now applies to the compiler, I see now reason to emit
VFP instructions and then let the software floating implementation to
decode it and emulate it.
The compiler can just emit calls to floating point emulation routines
(and we can do some trickery so that the compiler knows those
routines will preserve all floating point registers.)
|
|
Switched to Go 1.6 milestone, because we have to redesign
the soft float support to speed things up. Another motivation
for the redesign would be adding another architecture that
also needs soft FP (e.g. mips/mips64)
|
|
For now can we skip or shorten this test in testing.Short() mode when GOARM=="5" ? |
|
@minux - do you know why generating random integers is affected by the
speed of floating point operations ? Is this something we can avoid ?
|
|
$ /usr/bin/time ./rand.test -test.v -test.short
=== RUN TestStandardNormalValues
--- PASS: TestStandardNormalValues (0.78s)
=== RUN TestNonStandardNormalValues
--- PASS: TestNonStandardNormalValues (2.68s)
=== RUN TestStandardExponentialValues
--- PASS: TestStandardExponentialValues (0.74s)
=== RUN TestNonStandardExponentialValues
--- PASS: TestNonStandardExponentialValues (1.42s)
=== RUN TestNormTables
--- PASS: TestNormTables (0.02s)
=== RUN TestExpTables
--- PASS: TestExpTables (0.05s)
=== RUN TestFloat32
--- PASS: TestFloat32 (152.13s)
=== RUN TestRegress
--- PASS: TestRegress (0.01s)
=== RUN Example
--- PASS: Example (0.00s)
=== RUN Example_rand
--- PASS: Example_rand (0.00s)
PASS
157.82user 0.34system 2:37.85elapsed 100%CPU (0avgtext+0avgdata
18752maxresident)k
0inputs+0outputs (0major+1223minor)pagefaults 0swaps
As you can see, most of the time is spent in TestFloat32, which uses a lot
of floating point
instructions.
|
|
Hmm, what do you think of skipping that test for arm5 only? On Wed, 13 May 2015 16:47 Minux Ma notifications@github.com wrote:
|
|
I wonder if it would be a good or bad idea to use the new math/big.Float stuff in the emulation. |
|
/cc @griesemer per previous comment |
|
@robpike I don't know the details of the emulation, but I suspect using math/big.Float would not be good. For one, it also needs (machine) floating-point operations. |
|
One of the reason is perhaps the floating point functions are slow
(@griesemer, the code is at runtime/softfloat64.go, do you see any
obvious performance problems?)
The other problem is the unnecessary overhead is too big. We encode
the VFP instructions into the binary, and then put a call _sfloat before
a block of VFP instructions. The _sfloat function will read the
instructions,
decode them and emulate them.
We have to use this approach because we used to lay out instruction
only during linking (pre-liblink days), so the compiler doesn't know if
we're targeting GOARM=5 or GOARM=6/7. Now that the compiler
knows GOARM, we can definitely do better. I filed #10846 for the
overhead problem.
|
|
@minux There's no obvious low-hanging fruit I can see. It's hard to make this fast w/o making it incomprehensible. |
|
Thanks Robert. I guess for 1.6 we should remove the emulation
overhead first and then see if we should sacrifice code clarity for
performance in the software FP functions.
|
I just noticed on Scaleway, go test -short math/rand takes 172 seconds:
Figure out why.
The rest:
/cc @davecheney
The text was updated successfully, but these errors were encountered: