From: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Inaccurate results from numeric ln(), log(), exp() and pow() |
Date: | 2015-09-16 16:03:55 |
Message-ID: | CAEZATCXctUJGcpccWPHp_J2NQuV9U17rzxNV9LsFRfTGnpHu3Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 16 September 2015 at 16:14, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> wrote:
> On 16 September 2015 at 14:49, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
>>> AFAICT, this kind of slowdown only happens in cases like this where a
>>> very large number of digits are being returned.
>>
>> Can you clarify "very large"?
>>
>
> I haven't done much performance testing because I've been mainly
> focussed on accuracy. I just did a quick test of exp() for various
> result sizes. For results up to around 50 digits, the patched code was
> twice as fast as HEAD. After that the gap narrows until at around 250
> digits they become about the same speed, and beyond that the patched
> code is slower. At around 450 digits the patched code is twice as
> slow.
>
OK, scratch that. I managed to compare an optimised build with a debug
build somehow.
Comparing 2 optimised builds, it's still 2x faster at computing 16 or
17 digits, becomes about the same speed at 30 digits, and is 2x slower
at around 60 digits. So not nearly as impressive, but not too bad
either.
I'll try to do some more comprehensive performance testing over the
next few days.
Regards,
Dean
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-09-16 16:10:14 | Re: pltcl: sentence improvement |
Previous Message | Merlin Moncure | 2015-09-16 15:54:56 | Re: Inaccurate results from numeric ln(), log(), exp() and pow() |