On Fri, 4 Oct 2024 22:42:18 GMT, Raffaello Giulietti <rgiulie...@openjdk.org> 
wrote:

>> @rgiulietti Though, it's also true that if I want to do astronomical 
>> calculations, I probably have a machine that allows me to do so, and so I'd 
>> like to be able to make the most of it...
>
> `BigDecimal` was not designed to do astronomical computations. One would 
> probably use other libraries for that, e.g., [GMP](https://gmplib.org/) and 
> would not be interested too much in "stripping trailing zeros".
> The focus of this class is mainly commercial applications, where decimal 
> arithmetic is sometimes mandated by regulators.
> 
> So I'd expect that most usages, for example SQL or commercial application 
> workloads, will process numbers with a few dozens of digits, maybe sometimes 
> some hundreds digits for intermediate results. So I think that accelerating 
> for these sizes makes the most practical sense.
> 
> With modest memory and CPU costs, I think even one million digits or so might 
> be processed reasonably fast.
> My point is that there's room for improvement in these range of sizes, but 
> perhaps not for larger ones.
> 
> More importantly, though, I'd like to avoid one single computation to affect 
> the resident memory footprint of a JVM instance for its entire lifetime.

@rgiulietti FYI, I have found that `BigInteger` has already a cache for the 
repeated squares that uses in radix string conversion, and it is provided by 
the method `BigInteger.getRadixConversionCache(int radix, int exponent)`. 
Although, I don't know if it would be a good idea to use it, because it 
computes all the squares up to `radix^(2^exponent)`, and this may not be 
necessary but could cost a lot of running time and memory if the number to 
strip is very large...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21323#discussion_r1790787304

Reply via email to