RFR: 8285868: x86_64 intrinsics for floating point methods isNaN, isFinite and isInfinite [v6]
Jatin Bhateja
jbhateja at openjdk.java.net
Wed May 18 06:50:12 UTC 2022
On Wed, 18 May 2022 05:17:44 GMT, Srinivas Vamsi Parasa <duke at openjdk.java.net> wrote:
>> We develop optimized x86_64 intrinsics for the floating point class check methods `isNaN()`, `isFinite()` and `IsInfinite()` for Float and Double classes. JMH benchmarks show ~6x improvement for `isNan()`, ~2x improvement for `isInfinite()` and 40% gain for `isFinite()` using` vfpclasss(s/d)` instructions.
>>
>>
>> JMH Benchmark (ns/op) Baseline This PR (WITH vfpclassss/sd) Speedup
>>
>> FloatClassCheck.testIsFinite 0.559 0.4 1.4x
>> FloatClassCheck.testIsInfinite 0.828 0.386 2.15x
>> FloatClassCheck.testIsNaN 2.589 0.387 6.7x
>> DoubleClassCheck.testIsFinite 0.568 0.414 1.37x
>> DoubleClassCheck.testIsInfinite 0.836 0.395 2.11x
>> DoubleClassCheck.testIsNaN 2.592 0.393 6.6x
>>
>> JMH Benchmark (ns/op) Baseline This PR (WITHOUT vfpclassss/sd) Speedup
>> FloatClassCheck.testIsFinite 0.561 0.468 1.2x
>> FloatClassCheck.testIsInfinite 0.793 0.491 1.61x
>> FloatClassCheck.testIsNaN 2.587 0.469 5.5x
>> DoubleClassCheck.testIsFinite 0.561 0.592 0.94x
>> DoubleClassCheck.testIsInfinite 0.828 0.592 1.4x
>> DoubleClassCheck.testIsNaN 2.593 0.594 4.4x
>
> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
>
> use 0x1 to be simpler
src/hotspot/cpu/x86/x86_64.ad line 11183:
> 11181: ins_pipe(pipe_slow);
> 11182: %}
> 11183:
Should this be guarded by LP64 ? since associated macro assembly routines have that check ?
Also match_rule_supported vector should prevent intrinsifying these for 32 bit platform if you do not plan to handle them.
src/hotspot/share/opto/fpclassnode.hpp line 65:
> 63: virtual int Opcode() const;
> 64: const Type* bottom_type() const { return TypeInt::BOOL; }
> 65: virtual uint ideal_reg() const { return Op_RegI; }
None of the IR nodes handle constant folding scenarios.
test/micro/org/openjdk/bench/java/lang/DoubleClassCheck.java line 70:
> 68: public void testIsFinite() {
> 69: for (int i = 0; i < BUFFER_SIZE; i++) {
> 70: outputs[i] = Double.isFinite(inputs[i]) ? false : true;
Any specific reason to explicitly add conditional check to return true/false when isFinite returns bool value ?
test/micro/org/openjdk/bench/java/lang/DoubleClassCheck.java line 78:
> 76: public void testIsInfinite() {
> 77: for (int i = 0; i < BUFFER_SIZE; i++) {
> 78: outputs[i] = Double.isInfinite(inputs[i]) ? false : true;
Any specific reason to explicitly add conditional check to return true/false when isInfinit returns bool value ?
test/micro/org/openjdk/bench/java/lang/DoubleClassCheck.java line 86:
> 84: public void testIsNaN() {
> 85: for (int i = 0; i < BUFFER_SIZE; i++) {
> 86: outputs[i] = Double.isNaN(inputs[i]) ? false : true;
Any specific reason to explicitly add conditional check to return true/false when isNaN returns bool value ?
test/micro/org/openjdk/bench/java/lang/FloatClassCheck.java line 45:
> 43: public class FloatClassCheck {
> 44:
> 45: RandomGenerator rng;
Just a suggestion we can also create one benchmark to handle both the floating point types.
test/micro/org/openjdk/bench/java/lang/FloatClassCheck.java line 70:
> 68: public void testIsFinite() {
> 69: for (int i = 0; i < BUFFER_SIZE; i++) {
> 70: outputs[i] = Float.isFinite(inputs[i]) ? false : true;
Same a above
test/micro/org/openjdk/bench/java/lang/FloatClassCheck.java line 78:
> 76: public void testIsInfinite() {
> 77: for (int i = 0; i < BUFFER_SIZE; i++) {
> 78: outputs[i] = Float.isInfinite(inputs[i]) ? false : true;
Same a above
test/micro/org/openjdk/bench/java/lang/FloatClassCheck.java line 86:
> 84: public void testIsNaN() {
> 85: for (int i = 0; i < BUFFER_SIZE; i++) {
> 86: outputs[i] = Float.isNaN(inputs[i]) ? false : true;
Same as above
-------------
PR: https://git.openjdk.java.net/jdk/pull/8459
More information about the hotspot-compiler-dev
mailing list