-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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 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: