[PING] Re: [9] RFR of 5100935: No way to access the 64-bit integer multiplication of 64-bit CPUs efficiently

[joe darcy]

Hi Brian,

Sorry for the belated review.

For multiplyFull, currently the wording is

  833      * Returns the product of the arguments allowing overflowed 
values within
  834      * the range of {@code long}.

I think it would work about as something like "Returns the exact 
mathematical product of the arguments."

Otherwise, looks okay.

Thanks,

-Joe


On 5/18/2016 12:09 PM, Brian Burkhalter wrote:
> Following up on the as yet unresolved thread initiated here:
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035289.html
>
> Thanks,
>
> Brian
>
> On Sep 21, 2015, at 11:15 AM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
>
>> Hello, Sergey,
>>
>> On Sep 19, 2015, at 12:51 PM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>>
>>> Hello, I have a related question about the adding of methods to the Math class. Some methods **Exact methods were added to the Math class in jdk8, which throws an exceptions in case of overflow. Is it possible to add the similar saturation arithmetic? It would be quite good to realize a full range of these methods, and give the chance to hotspot to use an intrinsic.
>> If there are particular methods of interest and there are no corresponding issues on file, then one or more issues should be filed in the Java Bug System so that we may consider and track them according to the usual process. As there is currently an attempt to address some of the omissions in the Math area, now would be a good time to get these issues on record. So I suggest that the interested parties do just that. I think that one issue containing several method requests would be sufficient if it concerns the same area of code.
>>
>> As to the compiler intrinsics, we are looking into adding a few math-related things here as well. This would be tracked by a separate issue which we would file ourselves.
>>
>> Regards,
>>
>> Brian
>>
>>> This is mostly request from the java2d team:
>>>
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2008-December/000954.html
>>> "I currently use an utility-class heavily for the XRender Java2D
>>> backend, which performs saturated casts:
>>>
>>> 1.) return (short) (x > Short.MAX_VALUE ? Short.MAX_VALUE : (x <
>>> Short.MIN_VALUE ? Short.MIN_VALUE : x));
>>> 2.) return (short) (x > 65535 ? 65535 : (x < 0) ? 0 : x);
>>>
>>> I spent quite some time benchmarking/tuning the
>>> protocol-generation-methods, and a lot of cycles are spent in those
>>> saturated casts, even if the utility methods are static.
>>> E.g. XRenderFillRectangle takes 40 cycles without clamping, but
>>> already 70 cycles with on my core2duo with hotspot-server/jdk 14.0.
>>> Hotspot seems to solve the problem always with conditional jumps,
>>> although well predictable ones.
>>>
>>> Modern processors seem to have support for this kind of operation, in
>>> x86 there's packssdw in MMX/SSE2.
>>> I think something like a saturated cast could be quite useful, there
>>> are already cast-methods in Long/Integer/Short - what do you think
>>> about adding saturated casts to that API?
>>> Those could be instrified to use MMX/SSE2 if available.
>>>
>>> If that would be too specific how hard would it be to add this kind of
>>> optimization to hotspot?
>>> How far does SIMD support in hotspot go (I read some time ago there've
>>> been some optimizations), if SIMD would be supported 4 casts could be
>>> done in a single cycle :)