Code review request: 6282196 There should be Math.mod(number, modulo) methods
Stephen Colebourne
scolebourne at joda.org
Wed Feb 22 16:49:03 UTC 2012
Thanks for the explanation, I don't think that the change in floorDiv
behaviour will cause JSR-310 a problem
Stephen
On 22 February 2012 16:21, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>
> On 02/22/2012 09:37 AM, Stephen Colebourne wrote:
>
> Can you explain why the mod implementation differs from that in JSR-310?
> https://github.com/ThreeTen/threeten/blob/master/src/main/java/javax/time/MathUtils.java#L401
>
> The code ((a % b) + b) % b; is short and involves no branches, which
> should aid performance and inlining. Is this to do with accepting a
> negative second argument? Performance testing?
>
> For floorMod, the numeric results are the same but the performance is
> slightly better.
>
> The performance difference is very noticeable for long's, using
> a single divide and a multiply with the branch is about 1.5 times as fast
> as the alternative using two % operations.
>
> For int's the difference was minimal but still faster. I did not compare
> against
> floating point divide.
>
> Since it depends on the performance of the divide instruction it will
> be sensitive to specific processors. For interpreters and devices
> without floating point hardware (yes they exist) and slower hardware
> minimizing
> the number of divides makes sense. I would rather not try to tune for
> specific hardware and leave that to the VM.
>
>
> I'd like to see performance numbers comparing the two approaches, as
> JSR-310 might need to continue using the double % version if it is
> faster.
>
> Similarly, the proposed floorDiv requires evaluation of the complex if
> statement every time, whereas the JSR-310 one only requires an if
> check against zero. Whats the rationale for the difference, which is
> intuitively (non-proven) slower.,
>
> For floorDiv, the results are different when the sign of the divisor is
> negative.
> Using the definition of the largest integer less than the quotient with the
> arguments (4, -3) should be -1.3333, the largest integer less than that is
> -2.
> The JSR 310 expression (a/v) evaluates to -1.
>
> I choose to be consistent with the Math.floor behavior.
>
> Roger
>
>
>
>
> thanks
> Stephen
>
>
> On 22 February 2012 14:24, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>
> Hi,
>
> 6282196 There should be Math.mod(number, modulo) methods
> <http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6282196>
>
> Requests that floor and modulus methods be provided for primitive types.
> Floor division is pretty straight-forward, rounding toward minus infinity.
> For modulus of int and long, the sign and range follow the exiting floor
> method
> in java.util.Math and satisfy the relation that mod(x, y) = (x - floorDiv(x,
> y) * y).
>
> Please review and comment,
> http://cr.openjdk.java.net/~rriggs/6282196.1/
>
> Thanks, Roger
>
>
>
More information about the core-libs-dev
mailing list