Commit Graph

3 Commits

Author SHA1 Message Date
Neil Fuller
33253a4baa Switch from FloatMath -> Math and Math.hypot where possible
The motivation is an API change: FloatMath is going to be
deprecated and/or removed. Performance is not the goal of
this change.

That said...

Math is faster than FloatMath with AOT compilation.

While making the change, occurances of:

{Float}Math.sqrt(x * x + y * y) and
{Float}Math.sqrt({Float}Math.pow(x, 2) + {Float}Math.pow(y, 2))

have been replaced with:

{(float)} Math.hypot(x, y)

Right now there is no runtime intrinsic for hypot so is not faster
in all cases for AOT compilation:

Math.sqrt(x * x + y * y) is faster than Math.hypot(x, y) with
AOT, but all other combinations of FloatMath, use of pow() etc.
are slower than hypot().

hypot() has the advantage of being self documenting and
could be optimized in future. None of the behavior differences
around NaN and rounding appear to be important for the cases
looked at: they all assume results and arguments are in range
and usually the results are cast to float.

Different implementations measured on hammerhead / L:

AOT compiled:

[FloatMath.hypot(x, y)]
benchmark=Hypot_FloatMathHypot} 633.85 ns; σ=0.32 ns @ 3 trials

[FloatMath.sqrt(x*x + y*y)]
benchmark=Hypot_FloatMathSqrtMult} 684.17 ns; σ=4.83 ns @ 3 trials

[FloatMath.sqrt(FloatMath.pow(x, 2) + FloatMath.pow(y, 2))]
benchmark=Hypot_FloatMathSqrtPow} 1270.65 ns; σ=12.20 ns @ 6 trials

[(float) Math.hypot(x, y)]
benchmark=Hypot_MathHypot} 96.80 ns; σ=0.05 ns @ 3 trials

[(float) Math.sqrt(x*x + y*y)]
benchmark=Hypot_MathSqrtMult} 23.97 ns; σ=0.01 ns @ 3 trials

[(float) Math.sqrt(Math.pow(x, 2) + Math.pow(y, 2))]
benchmark=Hypot_MathSqrtPow} 156.19 ns; σ=0.12 ns @ 3 trials

Interpreter:

benchmark=Hypot_FloatMathHypot} 1180.54 ns; σ=5.13 ns @ 3 trials
benchmark=Hypot_FloatMathSqrtMult} 1121.05 ns; σ=3.80 ns @ 3 trials
benchmark=Hypot_FloatMathSqrtPow} 3327.14 ns; σ=7.33 ns @ 3 trials
benchmark=Hypot_MathHypot} 856.57 ns; σ=1.41 ns @ 3 trials
benchmark=Hypot_MathSqrtMult} 1028.92 ns; σ=9.11 ns @ 3 trials
benchmark=Hypot_MathSqrtPow} 2539.47 ns; σ=24.44 ns @ 3 trials

Bug: https://code.google.com/p/android/issues/detail?id=36199
Change-Id: I06c91f682095e627cb547d60d936ef87941be692
2014-10-01 14:04:15 +01:00
Bernd Holzhey
6fd5e0ac51 Fix calculation of the next twilight update for locations where the day or night never ends. 2010-02-23 06:04:33 +01:00
Bernd Holzhey
bfca3a0056 Add the automatic handling of night/notnight UI modes.
The automatic switching between night/notnight is based on the calulcation of
the civil twilight of the current location. The location is mainly retrieved
from the NetworkLocationProvider.

Automatic switching will only be available, when
1) the device is in UI_MODE_TYPE_CAR
2) the setting for the UI mode are set to 'automatic'

If mode is set to automatic, the next twilight is caluclated and
an alarm is set that timestamp. The alarm will trigger a new calculation
of the twilight and sets the UI_MODE_NIGHT to the appropriate value.

	modified:   services/java/com/android/server/DockObserver.java
	new file:   services/java/com/android/server/TwilightCalculator.java
2010-02-16 17:10:39 +01:00