gianm commented on code in PR #19768:
URL: https://github.com/apache/druid/pull/19768#discussion_r3885404148
##########
docs/configuration/index.md:
##########
@@ -652,7 +652,7 @@ the `expression` aggregator/post-aggregator, and any SQL
functions that lower to
|`druid.expressions.homogenizeNullMultiValueStringArrays`|If true, multi-value
string expression input values of `null`, `[]`, and `[null]` are all coerced to
`[null]`. Provided for backwards compatibility with Druid 0.22 and earlier. If
false (the default), this coercion only happens when single-value expressions
are implicitly mapped across multi-value rows, so the single-valued expression
is evaluated with an input of `null`.|false|
|`druid.expressions.allowVectorizeFallback`|If true, the vectorized query
engine handles expressions without a native vectorized implementation using a
fallback processor that invokes the scalar expression evaluator in a loop. If
false, such expressions cannot be vectorized and the query falls back to the
non-vectorized engine.|true|
|`druid.expressions.useVectorApi`|If true, vectorized expression vector
processors and numeric vector aggregators dispatch to SIMD specializations
backed by the JDK incubator Vector API (`jdk.incubator.vector`) where
available. Requires `--add-modules=jdk.incubator.vector` on the JVM command
line (see [strong encapsulation](../operations/java.md#strong-encapsulation)).
Off by default while the Vector API remains an incubator JDK feature.|false|
-|`druid.expressions.useVectorMathApi`|If true (and `useVectorApi` is also
true), math expressions whose SIMD path is backed by the JDK's VO_MATHLIB
routing (Intel SVML on x86, SLEEF on Arm) dispatch to that SIMD path. Results
can differ from the scalar `Math.<op>` by up to a few ulps, and the exact bits
can shift once the JIT promotes the SIMD loop from C1 to C2, meaning a
long-running query can produce different bits for the same input across the
tier transition. Safe for `SUM`/`MIN`/`MAX`/range-filter workloads; **do not
enable** if queries rely on exact-bit equality of these functions (for example
`GROUP BY sin(x)` where all rows with the same `x` must land in the same group,
or `WHERE sin(x) = sin(y)`). Off by default.|false|
+|`druid.expressions.useVectorMathApi`|When `useVectorApi` is true, controls
whether math expressions whose SIMD path is backed by the JDK's VO_MATHLIB
routing (Intel SVML on x86, SLEEF on Arm) dispatch to that SIMD path. Results
can differ from the scalar `Math.<op>` by a few ulps (the parity test bounds
this at 2 ulps), and the exact bits can shift once the JIT promotes the SIMD
loop from C1 to C2 during a long-running query. In general applications should
not rely on bit-for-bit equality of floating-point results, and round or
truncate first when using for grouping or equality comparisons. This flag
exists as an escape hatch for legacy queries that rely on `Math.<op>` bits
without rounding. Has no effect unless `useVectorApi` is also true. On by
default when `useVectorApi` is enabled.|true|
Review Comment:
The docs shouldn't mention "the parity test", that's a developer thing. The
docs are for users. If we can't offer a specific bound here then try language
like "SIMD and non-SIMD results can differ slightly"
##########
processing/src/main/java/org/apache/druid/math/expr/ExpressionProcessing.java:
##########
@@ -45,19 +45,19 @@ public class ExpressionProcessing
@VisibleForTesting
public static void initializeForTests()
{
- INSTANCE = new ExpressionProcessingConfig(null, null, null, null);
+ INSTANCE = new ExpressionProcessingConfig(null, null, null, null, null);
}
@VisibleForTesting
public static void initializeForHomogenizeNullMultiValueStrings()
{
- INSTANCE = new ExpressionProcessingConfig(null, true, null, null);
+ INSTANCE = new ExpressionProcessingConfig(null, true, null, null, null);
}
@VisibleForTesting
public static void initializeForVectorApiTests()
{
- INSTANCE = new ExpressionProcessingConfig(null, null, null, true);
+ INSTANCE = new ExpressionProcessingConfig(null, null, null, true, true);
Review Comment:
@clintropolis could you please opine on this?
--
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]
