Jackie-Jiang commented on code in PR #20249:
URL: https://github.com/apache/pinot/pull/20249#discussion_r4568735763
##########
pinot-segment-spi/src/main/java/org/apache/pinot/segment/spi/memory/PrimitiveArrays.java:
##########
@@ -21,24 +21,26 @@
import java.nio.ByteBuffer;
-/// Bulk reads of primitive arrays from a [ByteBuffer] through its typed
views, and the threshold below which one
-/// access per value beats a view. The class is stateless and thread-safe.
+/// Bulk reads of primitive arrays from a [ByteBuffer] through its typed
views. The class is stateless and thread-safe.
+///
+/// On a little-endian CPU, a copy through a big-endian view
(`asIntBuffer().get(int[])` and the like) swaps the bytes
+/// in a native call with a fixed cost of 20 to 40 ns, so a short read gets
one value at a time instead. With JMH on
+/// JDK 25, reading from heap and direct buffers held in a field (as a
deserializer gets them), the view was 14 to 24%
+/// faster than one value at a time at 128 longs or doubles on Intel Xeon
6973P-C, AMD EPYC 7763 and Neoverse N2
+/// machines, and 14 to 35% slower on an Apple M3 Max, where it caught up at
160 to 192. For ints and floats, one value
+/// at a time took several times as long in some JVM launches as in others on
those three machines, so no threshold
+/// suits every launch; on the M3 the view caught up at 96 to 128.
public final class PrimitiveArrays {
private PrimitiveArrays() {
}
- // TODO: Retune this threshold. JMH runs on aarch64 (Apple M3 Max, JDK 25)
put the crossover at about 110-200 values
- // for reads, 300-500 for int writes and beyond 4096 for double writes, so
a single threshold may not fit them all.
- /// Below this number of values, reads and writes through a big-endian typed
view (`asIntBuffer().get(int[])` and
- /// the like) are slower than one access per value. On a little-endian CPU
the bulk copy swaps the bytes in a native
- /// call with a fixed cost of about 10-40 ns, while a single-value access
compiles to an inlined byte swap. Measured
- /// with BenchmarkPrimitiveListDeserialize and
BenchmarkPagedPinotOutputStream on aarch64 and x86_64.
- public static final int MIN_BULK_VALUES = 64;
+ /// The `read*` methods read at least this many values through a typed view,
and fewer one at a time.
+ public static final int MIN_BULK_READ_VALUES = 128;
Review Comment:
Lowered `MIN_BULK_READ_VALUES` to 96. In our runs, 96 is the first measured
length at which long and double reads through the view are at least even on all
three server CPUs (view / one value at a time 0.87 to 0.99 on the Intel runner,
0.84 to 0.86 on the AMD one, 0.92 to 0.95 on the Neoverse N2), which matches
your 96 to 127 numbers on the Xeon 6975P-C. The cost lands on the M3, where 96
to 159 longs or doubles are now about 40% slower, and on direct-buffer int and
float reads on the Neoverse N2, which favor one value at a time up to about 200.
##########
pinot-segment-spi/src/main/java/org/apache/pinot/segment/spi/memory/PrimitiveArrays.java:
##########
@@ -21,24 +21,26 @@
import java.nio.ByteBuffer;
-/// Bulk reads of primitive arrays from a [ByteBuffer] through its typed
views, and the threshold below which one
-/// access per value beats a view. The class is stateless and thread-safe.
+/// Bulk reads of primitive arrays from a [ByteBuffer] through its typed
views. The class is stateless and thread-safe.
+///
+/// On a little-endian CPU, a copy through a big-endian view
(`asIntBuffer().get(int[])` and the like) swaps the bytes
+/// in a native call with a fixed cost of 20 to 40 ns, so a short read gets
one value at a time instead. With JMH on
+/// JDK 25, reading from heap and direct buffers held in a field (as a
deserializer gets them), the view was 14 to 24%
+/// faster than one value at a time at 128 longs or doubles on Intel Xeon
6973P-C, AMD EPYC 7763 and Neoverse N2
+/// machines, and 14 to 35% slower on an Apple M3 Max, where it caught up at
160 to 192. For ints and floats, one value
Review Comment:
Fixed: the Javadoc now quotes only the Temurin 25.0.5 runs that the PR
tables show.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
