New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cmd/compile: Use SDIV and UDIV for ARM #19118
Comments
our division routine is very efficient, last time I benchmarked, it's even
faster than glibc's.
how much faster is the native div instruction?
I don't think we should add a new environment variable though. We can make
the div routine use the instruction automatically if the machine supports
it.
|
A hardware divider is usually much faster than a software one. However, there is no proper way to let the div routine decide in runtime.
|
There is no proper way to let the div routine decide in runtime. Unless the user specifies it explicitly. |
It is easy enough to check /proc/cpuinfo once on startup and cache the result. |
Check /proc/cpuinfo for "idiva" flag on startup might be a way, how are the core developers' opinion? |
Checking on startup sounds good to me. |
There are multiple ways to detect DIV instruction at runtime.
1. we can issue it and see if we get SIGILL,
2. we can use HWCAP auxv on Linux.
|
I would vote for call getauxval() / AT_HWCAP at startup. |
Seconded, AT_HWCAP is useful for this.
…On Thu, Feb 16, 2017 at 3:35 PM, Ben Shi ***@***.***> wrote:
I would vote for call getauxval() / AT_HWCAP at startup.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#19118 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAAcAyBVME3_goMzPfLZPPS9LatiAVXAks5rc9IggaJpZM4MChHn>
.
|
I have implemented this feature. A rough test shows the performance improves 40-50%. |
For a rough test case **package main import "fmt" func main() {
}** The hardware divider outputs And the software divider outputs |
CL https://golang.org/cl/37496 mentions this issue. |
How do we proceed in CL 37496? Keep the simulated DIV/DIVU/MOD/MODU, or remove them? |
In patch set 14 of CL 37496,
|
Any conclusion for this issue? Whether keep simulated div/mod or not? |
The hardware divider is an optional component of ARMv7. This patch detects whether it is available in runtime and use it or not. 1. The hardware divider is detected at startup and a flag is set/clear according to a perticular bit of runtime.hwcap. 2. Each call of runtime.udiv will check this flag and decide if use the hardware division instruction. A rough test shows the performance improves 40-50% for ARMv7. And the compatibility of ARMv5/v6 is not broken. fixes golang#19118 Change-Id: Ic586bc9659ebc169553ca2004d2bdb721df823ac Reviewed-on: https://go-review.googlesource.com/37496 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
The UDIV and SDIV instructions are optional on ARM, so arm gcc generates __armeabi_udiv(a, b) for a/b by default, but it also emits "udiv a, b" while -march=armv7ve is specified.
Golang should also allow user to choose hardware or software division. Maybe by adding a GOARMHDIV environment variable?
The text was updated successfully, but these errors were encountered: