Need reviewer: JDK 8 CR for Support Integer overflow
eamonn at mcmanus.net
Fri Feb 3 09:33:02 PST 2012
Hacker's Delight gives a formula equivalent to this one on page 27:
((x ^ r) & (y ^ r)) < 0
Having said that, I think Florian's assertion that such a rewrite will be
faster needs proof. In the original form...
(x ^ r) < 0 && (x ^ y) >= 0
...the first condition will be false half the time for random inputs and
(hand-waving) probably a lot more than half the time for typical inputs. To
the extent that the difference is measurable at all, I would not like to
have to bet on which alternative is faster, and the original form is
definitely easier to read as "both arguments have the same sign and the
result has the opposite sign."
On 3 February 2012 09:07, Joe Darcy <joe.darcy at oracle.com> wrote:
> On 02/03/2012 06:44 AM, Florian Weimer wrote:
>> * Roger Riggs:
>> The boolean expression can be refactored. (Only bit-31 is significant).
>>> But it becomes pretty inscrutable.
>>> (x ^ r)< 0&& (x ^ y)>= 0 becomes
>>> (x ^ r)< 0&& (~(x ^ y))< 0 becomes
>>> ((x ^ r)& ~(x ^ y))< 0
>> That's what I got in my second attempt, too. It doesn't result in a
>> longer dependency chain because the left side of the& is two operations
>> deep, too. Therefore, this version should be faster (at least after
>> compilation), independent of the input arguments.
> These sorts of concerns and lovingly (and laboriously!) detailed to Hank
> Warren's bit-twiddling tome "Hacker's Delight" (http://www.hackersdelight.
> **org/ <http://www.hackersdelight.org/>).
> Roger's initial code used one of the recommend idioms from that source.
> We should stick with those idioms unless there is a good reason not to.
More information about the core-libs-dev