|
|
Message-Id: <p9u03431h1mp.fsf@thym>
Date: Mon, 16 Feb 2026 03:18:38 +0100
From: Paul Zimmermann <Paul.Zimmermann@...ia.fr>
To: Szabolcs Nagy <nsz@...t70.net>
Cc: musl@...ts.openwall.com
Subject: Re: Accuracy of Mathematical Functions
Hi Szabolcs,
here is the result of size -A on the acosh code from GNU libc
(integrated from CORE-MATH):
$ size -A ./math/e_acosh.o
./math/e_acosh.o :
section size addr
.text 4054 0
.data 0 0
.bss 0 0
.rodata 2656 0
.rodata.cst8 376 0
.rodata.cst16 16 0
.debug_info 8382 0
.debug_abbrev 818 0
.debug_loclists 9253 0
.debug_aranges 48 0
.debug_rnglists 819 0
.debug_line 3972 0
.debug_str 730 0
.debug_line_str 301 0
.comment 32 0
.note.GNU-stack 0 0
.eh_frame 240 0
Total 31697
Paul
> Date: Mon, 16 Feb 2026 01:03:42 +0100
> From: Szabolcs Nagy <nsz@...t70.net>
> Cc: musl@...ts.openwall.com
>
> * Paul Zimmermann <Paul.Zimmermann@...ia.fr> [2026-02-15 09:18:49 +0100]:
> > from a GNU libc 2.43 build, which integrates atanh from CORE-MATH:
>
> ah, i missed this.
> good work
> thanks
>
> > $ ls -l ./math/e_acosh.o
> > -rw-r--r-- 1 zimmerma caramba 57696 Jan 29 14:06 ./math/e_acosh.o
>
> you should use 'size' from binutils to see the
> actual code size (or size -A to see .text and
> .rodata separately), that's what matters at
> runtime. writable data should be 0.
>
> i think up to 4k lookup table is acceptable
> per function, beyond that one can start to
> worry about tiny vs fast tradeoffs.
>
> >
> > You can find some timings about the integration of acosh in GNU libc here:
> >
> > https://sourceware.org/pipermail/libc-alpha/2025-October/170985.html
> >
> > (there are similar timings for other functions integrated in GNU libc)
> >
> > > eventually it may be worth considering cr in libc.
> >
> > Best regards,
> > Paul
>
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.