DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 60IMiFxc3795026
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EE6D34BA2E1D
Message-ID: <3c56778a-870c-4bae-a855-6b96392870c8@SystematicSW.ab.ca>
Date: Sun, 18 Jan 2026 15:43:21 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Log2 seems inefficient
Content-Language: en-CA
To: cygwin AT cygwin DOT com
References: <226987210 DOT 591128 DOT 1768766440723 AT connect DOT xfinity DOT com>
Organization: Systematic Software
In-Reply-To: <226987210.591128.1768766440723@connect.xfinity.com>
Precedence: list
From: Brian Inglis via Cygwin <cygwin AT cygwin DOT com>
Reply-To: cygwin AT cygwin DOT com
Cc: Brian Inglis <Brian DOT Inglis AT SystematicSW DOT ab DOT ca>,
        Paul Zimmermann <Paul DOT Zimmermann AT inria DOT fr>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Errors-To: cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com
Sender: "Cygwin" <cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com>
Content-Transfer-Encoding: 8bit

On 2026-01-18 13:00, KENNON J CONRAD via Cygwin wrote:
> I am not an experienced cygwin user but have been using it to compile code on
> Windows (gcc), so I may be leaving out some key details.
> My issue is that for every log2 call in my code there is a divide that
> follows a log library call in the assembly code.
> It appears to be related to these lines in math.h:
> #if !defined(__cplusplus)
> #define log2(x) (log (x) / _M_LN2)
> #endif
> My questions are:  If log(x) is used, wouldn't it be faster to multiply by constant (1/LN2) instead of divide by constant (LN2)?  And wouldn't it be even more efficient to compute log2 directly instead of computing the natural log and then converting it to log2?
> I realize this is not a "bug", it just doesn't seem very optimal from an speed standpoint.

You are probably correct, as the FP exponent provides the first order estimate 
of the result, and only the mantissa bits need converted, with possibly minor 
iterative/unrolled tweaking for ultimate accuracy.

When the code was updated by ARM in 2018, the commit message said:

"...
With default settings the worst case error in nearest rounding mode is 0.547 ULP 
with inlined fma and fma contraction.
It uses a 1 KB lookup table,
...
Note that the math.h header defines log2(x) to be log(x)/Ln2, this is
not changed, so the new code is only used if that macro is suppressed."

which may be to reduce the amount of space used by math tables in embedded 
libraries, the most numerous newlib targets, especially for minimal 
implementations like Nano libc, whereas hosted implementations like Cygwin, 
RTEMS, others may prefer to use the table.

I think that perhaps Cygwin should interpose #ifdef log2/#undef log2 where these 
space saving measures have been employed, given the amount of space used by 
locales, charset support including Unicode, dates/times, ..., and you can do so 
yourself.

You may want to check which implementation gives the quickest and most accurate 
results before making changes.

Paul Zimmerman regularly posts library math function comparisons on the newlib 
and comparable library mailing lists, available at:

	https://members.loria.fr/PZimmermann/papers/accuracy.pdf

that should give you an idea of the current state of the functions, if he is 
even aware of the issue.

You can find his posts at:

	https://inbox.sourceware.org/newlib/?q=loria.fr

-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retrancher  but when there is no more to cut
                                 -- Antoine de Saint-Exupéry

-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple