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
