Skip to content
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

math/big: avoid DIVQ #9246

Closed
griesemer opened this issue Dec 10, 2014 · 4 comments
Closed

math/big: avoid DIVQ #9246

griesemer opened this issue Dec 10, 2014 · 4 comments

Comments

@griesemer
Copy link
Contributor

Suggested by Torbjörn Granlund (personal communication):

"
Division:

The DIVQ instruction is terrible. Don't ever use it. You might
want to take a look at "Improved Division by Invariant Integers" by
me and a collegue of mine. Your loop will become about 10 times
faster. You need to apply this also to generic division (not just the
one-divisor-word case.
"

(paper reference: https://gmplib.org/~tege/division-paper.pdf)

@rsc
Copy link
Contributor

rsc commented Dec 10, 2014

The Go compiler already does this. If you want to know the sequence, write
a program with a constant divide and use go tool 6g -S.

@ianlancetaylor
Copy link
Contributor

I think the suggestion here is to do it when dividing in a loop by an invariant value that is only known at run time.

@griesemer
Copy link
Contributor Author

Ok, good to know. Note that Torbjörn's paper suggests that even for a non-constant divisor, division via mutiplication by inverse is faster:

"Somewhat surprisingly, a well-tuned Newton reciprocal followed by multiplication and adjustments wins over the hardware division instructions even for a single non-invariant division on modern 64-bit PC processors."

@andig
Copy link
Contributor

andig commented Oct 14, 2021

This has been implemented in https://golang.org/cl/250417

@golang golang locked and limited conversation to collaborators Jun 23, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants