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.burkhal...@oracle.com>
wrote:
Hello, Sergey,
On Sep 19, 2015, at 12:51 PM, Sergey Bylokhov <sergey.bylok...@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 :)
