On Fri, 17 Feb 2023 04:43:00 GMT, Xiaowei Lu wrote:
>> [JDK-8269667](https://bugs.openjdk.org/browse/JDK-8269667) has uncovered the
>> poor performance of BigDecimal.divide under certain circumstance.
>>
>> We confront similar situations when benchmarking Spark3 on TPC-DS test kit.
>> Accordin
On Fri, 17 Feb 2023 04:43:00 GMT, Xiaowei Lu wrote:
>> [JDK-8269667](https://bugs.openjdk.org/browse/JDK-8269667) has uncovered the
>> poor performance of BigDecimal.divide under certain circumstance.
>>
>> We confront similar situations when benchmarking Spark3 on TPC-DS test kit.
>> Accordin
On Wed, 1 Mar 2023 06:40:01 GMT, Xiaowei Lu wrote:
>>> > After making sure that `intVal` is even, and before attempting a division
>>> > by a power of 10, it might help to check if 5 divides `intVal` in the
>>> > first place. If it doesn't, there no point in performing the division.
>>> > It ca
On Fri, 17 Feb 2023 15:24:26 GMT, Raffaello Giulietti
wrote:
>>> After making sure that `intVal` is even, and before attempting a division
>>> by a power of 10, it might help to check if 5 divides `intVal` in the first
>>> place. If it doesn't, there no point in performing the division.
>>>
>
On Tue, 14 Feb 2023 03:20:14 GMT, Sergey Kuksenko wrote:
>> [JDK-8269667](https://bugs.openjdk.org/browse/JDK-8269667) has uncovered the
>> poor performance of BigDecimal.divide under certain circumstance.
>>
>> We confront similar situations when benchmarking Spark3 on TPC-DS test kit.
>> Acc
On Fri, 17 Feb 2023 08:58:13 GMT, Xiaowei Lu wrote:
> > After making sure that `intVal` is even, and before attempting a division
> > by a power of 10, it might help to check if 5 divides `intVal` in the first
> > place. If it doesn't, there no point in performing the division.
> > It can be sh
On Fri, 17 Feb 2023 04:42:50 GMT, Xiaowei Lu wrote:
> After making sure that `intVal` is even, and before attempting a division by
> a power of 10, it might help to check if 5 divides `intVal` in the first
> place. If it doesn't, there no point in performing the division.
>
> It can be shown t
On Thu, 16 Feb 2023 16:51:43 GMT, Raffaello Giulietti
wrote:
> After making sure that `intVal` is even, and before attempting a division by
> a power of 10, it might help to check if 5 divides `intVal` in the first
> place. If it doesn't, there no point in performing the division.
>
> It can
On Fri, 17 Feb 2023 04:36:08 GMT, Xiaowei Lu wrote:
> The pr looks promising in terms of performance. What makes sense to do:
>
> *) Don't rely on external benchmarks. It's fine if such exists, but anyway
> set of microbenchmarks (using JMH) will be much better. More clear, readable
> results,
> [JDK-8269667](https://bugs.openjdk.org/browse/JDK-8269667) has uncovered the
> poor performance of BigDecimal.divide under certain circumstance.
>
> We confront similar situations when benchmarking Spark3 on TPC-DS test kit.
> According to the flame-graph below, it is StripZeros that spends mo
On Tue, 14 Feb 2023 04:48:43 GMT, Xiaowei Lu wrote:
> The pr looks promising in terms of performance. What makes sense to do:
>
> *) Don't rely on external benchmarks. It's fine if such exists, but anyway
> set of microbenchmarks (using JMH) will be much better. More clear, readable
> results,
On Thu, 16 Feb 2023 16:51:43 GMT, Raffaello Giulietti
wrote:
> It can be shown that 5 divides `intVal` if and only if it divides the `long`
> sum of all `int`s in the mag array of `intVal`.
More precisely, the sum must be computed over the `mag` elements taken as
_unsigned_ values:
`sum += ma
On Thu, 16 Feb 2023 16:51:43 GMT, Raffaello Giulietti
wrote:
> After making sure that `intVal` is even, and before attempting a division by
> a power of 10, it might help to check if 5 divides `intVal` in the first
> place. If it doesn't, there no point in performing the division.
>
> It can
On Fri, 10 Feb 2023 10:00:05 GMT, Xiaowei Lu wrote:
> [JDK-8269667](https://bugs.openjdk.org/browse/JDK-8269667) has uncovered the
> poor performance of BigDecimal.divide under certain circumstance.
>
> We confront similar situations when benchmarking Spark3 on TPC-DS test kit.
> According to
On Fri, 10 Feb 2023 10:00:05 GMT, Xiaowei Lu wrote:
> [JDK-8269667](https://bugs.openjdk.org/browse/JDK-8269667) has uncovered the
> poor performance of BigDecimal.divide under certain circumstance.
>
> We confront similar situations when benchmarking Spark3 on TPC-DS test kit.
> According to
On Tue, 14 Feb 2023 03:20:14 GMT, Sergey Kuksenko wrote:
> The pr looks promising in terms of performance. What makes sense to do:
>
> *) Don't rely on external benchmarks. It's fine if such exists, but anyway
> set of microbenchmarks (using JMH) will be much better. More clear, readable
> res
On Fri, 10 Feb 2023 10:00:05 GMT, Xiaowei Lu wrote:
> [JDK-8269667](https://bugs.openjdk.org/browse/JDK-8269667) has uncovered the
> poor performance of BigDecimal.divide under certain circumstance.
>
> We confront similar situations when benchmarking Spark3 on TPC-DS test kit.
> According to
On Mon, 13 Feb 2023 03:54:07 GMT, Sergey Kuksenko wrote:
> As for TPC-DS [AUTO-RESULT] QueryTotal=1968s vs [AUTO-RESULT]
> QueryTotal=1934s that gives ~1.7% of performance difference. Are you sure
> that this small diff is a real diff, but not run-to-run variance?
These queries are separate an
Could you do that benchmark with e.g. JMH rather than taking the difference
of System.currentTimeMillis? That would probably make it easier to read
and trust the results.
On Sun, Feb 12, 2023, 7:56 PM Sergey Kuksenko wrote:
> On Fri, 10 Feb 2023 10:00:05 GMT, Xiaowei Lu wrote:
>
> > [JDK-82696
On Fri, 10 Feb 2023 10:00:05 GMT, Xiaowei Lu wrote:
> [JDK-8269667](https://bugs.openjdk.org/browse/JDK-8269667) has uncovered the
> poor performance of BigDecimal.divide under certain circumstance.
>
> We confront similar situations when benchmarking Spark3 on TPC-DS test kit.
> According to
On Sat, 11 Feb 2023 16:03:24 GMT, Sergey Kuksenko wrote:
> "The performance looks good." - Could you support this statement with some
> benchmark results? Thank you.
Hi, here is a detailed result
1. I have run the benchmark in
[JDK-8269667](https://bugs.openjdk.org/browse/JDK-8269667), which c
On Fri, 10 Feb 2023 10:00:05 GMT, Xiaowei Lu wrote:
> [JDK-8269667](https://bugs.openjdk.org/browse/JDK-8269667) has uncovered the
> poor performance of BigDecimal.divide under certain circumstance.
>
> We confront similar situations when benchmarking Spark3 on TPC-DS test kit.
> According to
[JDK-8269667](https://bugs.openjdk.org/browse/JDK-8269667) has uncovered the
poor performance of BigDecimal.divide under certain circumstance.
We confront similar situations when benchmarking Spark3 on TPC-DS test kit.
According to the flame-graph below, it is StripZeros that spends most of the
23 matches
Mail list logo
