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 S
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 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.
>
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 clea
we run Spark3.3.0 on Openjdk11, but it seems jdk version doesn’t have much
> impact on BigDecimal. Spark cluster consists of a main node and 2 core nodes,
> each has 4cores, 16g memory and 4x500GB storage.
Xiaowei Lu has updated the pull request incrementally with one additional
c
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 clea
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.
&g
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 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
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
[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
13 matches
Mail list logo
