Re: Inaccurate results from numeric ln(), log(), exp() and pow()

Поиск
Список
Период
Сортировка
От Dean Rasheed
Тема Re: Inaccurate results from numeric ln(), log(), exp() and pow()
Дата
Msg-id CAEZATCXctUJGcpccWPHp_J2NQuV9U17rzxNV9LsFRfTGnpHu3Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Inaccurate results from numeric ln(), log(), exp() and pow()  (Dean Rasheed <dean.a.rasheed@gmail.com>)
Ответы Re: Inaccurate results from numeric ln(), log(), exp() and pow()  (Dean Rasheed <dean.a.rasheed@gmail.com>)
Список pgsql-hackers
On 16 September 2015 at 16:14, Dean Rasheed <dean.a.rasheed@gmail.com> wrote:
> On 16 September 2015 at 14:49, Merlin Moncure <mmoncure@gmail.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Merlin Moncure
Дата:
Сообщение: Re: Inaccurate results from numeric ln(), log(), exp() and pow()
Следующее
От: Tom Lane
Дата:
Сообщение: Re: pltcl: sentence improvement