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

Add invSqrt #2

Closed
wants to merge 1 commit into from
Closed

Conversation

jmcwilliams403
Copy link
Contributor

This is the original Quake III Arena implementation of Fast InvSqrt() from id Tech 3, ported to Java using Float.floatToIntBits() and Double.doubleToLongBits(). May need to add a disclaimer that any observable performance difference over 1/Math.sqrt(x) is entirely system-dependent

This is the original Quake III Arena implementation of Fast InvSqrt() from id Tech 3, ported to Java using Float.floatToIntBits() and Double.doubleToLongBits(). May need to add a disclaimer that any observable performance difference over 1/Math.sqrt(x) is entirely system-dependent
@tommyettinger
Copy link
Owner

I just want to point out why this was closed: the method is sound and should work for the -0.5 power with good precision, but according to benchmarks I ran a while ago (partly in https://github.com/tommyettinger/assorted-benchmarks/blob/master/src/main/java/net/adoptopenjdk/bumblebench/examples/MathSqrtFloatBench.java ), this inverse approximation isn't as fast as 1f/(float)Math.sqrt(x) because sqrt is an intrinsic candidate on most JDKs. For cube root, an approximation like this is much faster than Math.cbrt(x), so the format is still useful, just not the specific case of the 0.5 or -0.5 power.

@tommyettinger
Copy link
Owner

So my old benchmark didn't test GraalVM (it wasn't usable on Windows for a while early on), and it turns out this code is significantly faster on Graal (> 40% higher throughput) while only being a tiny bit slower elsewhere (less than 5% slower on HotSpot, though since it's an approximation, it is less accurate). It looks like Graal doesn't have the same intrinsic optimizations that HotSpot has for Math.sqrt(), or they aren't as fast. I can't reopen this PR because of some Git reason ("main branch was force-pushed or recreated"), so I may recreate it with a notice about being a good choice if you distribute with or typically target GraalVM. There was one change I needed to make anyway; Float's int/float conversions are good on Desktop and Android, but are extremely slow by default on GWT. We use BitConversion here, which should inline to be the same as Float.intBitsToFloat() and related methods on desktop, while using an alternate (non-approximate) algorithm on GWT-only that is optimized for what it can do.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants