First paragraph should say: Thank you, that seems logical since log2() should be more natural (faster?) to compute than log(). But what you describe is almost exactly opposite of what I see with "GCC: (GNU) 13.4.0".
> On 01/21/2026 8:41 PM PST KENNON J CONRAD via Cygwin <[email protected]> > wrote: > > > Hello Jakob, > > Thank you, that seems logical since log2 should be more natural (faster?) > to compute log2() than log(). But what you describe is almost exactly of > what I see with "GCC: (GNU) 13.4.0". > > For this code snipet: > > uint8_t i; > double j = 0.0; > for (i = 1 ; i <= 10 ; i++) > j += log2((double)i); > > The assembler shows this for the loop (gcc -O3 -S test.c): > > .L2: > movzbl %bl, %eax > pxor %xmm0, %xmm0 > addl $1, %ebx > cvtsi2sdl %eax, %xmm0 > call log > divsd %xmm7, %xmm0 > addsd %xmm0, %xmm6 > cmpb $11, %bl > jne .L2 > > So it uses the log function in place of the log2 function with the argument > in xmm0 and the result in xmm0, and then divides the result by log2(e), which > is in xmm7. (The sum (j) is accumulated in xmm6.) > > From an efficiency standpoint, I find this to be...disappointing. Log2 > should be easier to compute, the divide should not be needed, and xmm7 gets > unnecessarily consumed to store the conversion constant. I even question > whether the pxor is necessary. > > Interestingly, if I compile with g++ -O3 -S test.c, I get something more > reasonable: > .L2: > movzbl %bl, %eax > pxor %xmm0, %xmm0 > addl $1, %ebx > cvtsi2sdl %eax, %xmm0 > call log2 > addsd %xmm0, %xmm6 > cmpb $11, %bl > jne .L2 > > So part of the solution may be for this old guy to figure out what it takes > to make the rest of his code c++ compliant. > > Best Regards, > > Kennon > > > > On 01/21/2026 6:33 PM PST Jakob Bohm via Cygwin <[email protected]> wrote: > > > > > > On 18/01/2026 21:00, KENNON J CONRAD via Cygwin wrote: > > > Hello, > > > > > > 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. > > Please note, that on the x86 and x86_64 platforms, the natural log > > function log() is often implemented in terms of the intrinsic log2() > > function multiplied by log(2), which is done by the instruction FYL2X, > > thus preferably the x86 family port of newlib should include an > > intrinsic or inline implementation such as something doing the > > assembler sequence FLD1, FXCH, FYL2X, which takes the arg in ST(0) > > and returns the log2() result in ST(0). For targets that tend to > > run the floating point subsystem in a mode other than traditional > > x87, perhaps finding similar inline code for SSE or MMX would be > > needed. Other libc implementations may include the needed code in > > gcc-compatible format already. > > > > Enjoy > > > > Jakob > > -- > > Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com > > Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 > > This public discussion message is non-binding and may contain errors. > > WiseMo - Remote Service Management for PCs, Phones and Embedded > > > > > > -- > > 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 > > -- > 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 -- 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
