SimdOps and NativeSimd ops refactored to remove duplicate code, Vecto… #498
Conversation
…rUtilSupport simplified for Native vs Panama
… tried with MemorySegments
| @@ -100,9 +100,9 @@ private static class check_compatibility { | |||
| public static final FunctionDescriptor DESC = FunctionDescriptor.of( | |||
| NativeSimdOps.C_BOOL ); | |||
|
|
|||
| public static final MethodHandle HANDLE = Linker.nativeLinker().downcallHandle( | |||
There was a problem hiding this comment.
I think I must have a newer version of jextract?
There was a problem hiding this comment.
These are generated with a version from February 2024, so very possible. Maybe we should make a note of the version used in the README so that we can avoid unnecessary churn if someone uses an old version again?
|
This is awesome. Looks really good to me. |
|
|
||
| import java.util.List; | ||
|
|
||
| final class PanamaVectorUtilSupport implements VectorUtilSupport { | ||
| class PanamaVectorUtilSupport implements VectorUtilSupport { | ||
| protected final SimdOps simdOps; |
There was a problem hiding this comment.
Is it needed to keep here an instance of SimdOps? It looks like previously it was static which is more efficient when no state is required to keep for method calls.
There was a problem hiding this comment.
Since the PR is using inheritance and function overloading for fromVectorFloat, I think we need runtime method resolution.
There was a problem hiding this comment.
We don't need separate SimdOps classes etc, we can move things to VectorSupportUtils implementations?
There was a problem hiding this comment.
That's not a bad idea. It might work.
| static final int PREFERRED_BIT_SIZE = FloatVector.SPECIES_PREFERRED.vectorBitSize(); | ||
| static final IntVector BYTE_TO_INT_MASK_512 = IntVector.broadcast(IntVector.SPECIES_512, 0xff); | ||
| static final IntVector BYTE_TO_INT_MASK_256 = IntVector.broadcast(IntVector.SPECIES_256, 0xff); | ||
|
|
||
| static final ThreadLocal<int[]> scratchInt512 = ThreadLocal.withInitial(() -> new int[IntVector.SPECIES_512.length()]); | ||
| static final ThreadLocal<int[]> scratchInt256 = ThreadLocal.withInitial(() -> new int[IntVector.SPECIES_256.length()]); | ||
|
|
||
| static float sum(ArrayVectorFloat vector) { | ||
| protected FloatVector fromVectorFloat(VectorSpecies<Float> SPEC, VectorFloat<?> vector, int offset) { |
There was a problem hiding this comment.
No local member variables in this class, why not make methods static?
There was a problem hiding this comment.
The method fromVectorFloat is solved at runtime using inheritance and overloading. Unless I'm missing a key Java feature, I think the methods cannot be static.
There was a problem hiding this comment.
Correct, we need the inheritance
| import java.util.List; | ||
|
|
||
| final class SimdOps { | ||
| class SimdOps { |
There was a problem hiding this comment.
Minor suggestion: Maybe having SimdOps as a singleton class would not be a bad idea
There was a problem hiding this comment.
LGTM. I think the consolidation here will ease future changes in this area. It's worth some basic benchmarking on this; this is touching areas that were fairly sensitive to small changes having major impact on how well C2 did. I'll defer on more minor questions around moving things out of SimdOps into VectorUtilSupport to those who are working with the codebase more frequently. Thanks!
|
Consensus seems to be we should remove the SimdOps stuff and move it into VectorSupport classes. I'll do that |
|
@MarkWolters is running some benchmarks on this branch to see if it is as performant as the previous version. |
|
I forgot to say, I ran the jmh benchmarks and saw no difference FYI |
|
Ok I reverted the jmh change and moved SimdOps and NativeSimdOps logic to VectorUtilSupport |
|
Additional performance testing by @MarkWolters looks good. |
…rUtilSupport simplified for Native vs Panama