Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 9 May 2013 12:02:01 -0400
From: Rich Felker <>
Subject: Re: Using float_t and double_t in math functions

On Thu, May 09, 2013 at 03:21:57PM +0200, Szabolcs Nagy wrote:
> * Rich Felker <> [2013-05-08 21:43:27 -0400]:
> > As far as I can tell, in most of the affected code, keeping excess
> > precision does not hurt the accuracy of the result, and it might even
> > improve the results. Thus, nsz and I discussed (on IRC) the
> > possibility of changing intermediate variables in functions that can
> > accept excess precision from float and double to float_t and double_t.
> > This would not affect the generated code at all on machines without
> > excess precision, but on x86 (without SSE) it eliminates all the
> > costly store/load pairs. As an example (on my test machine), it
> ie. it is only for i386 (without sse)
> (which is not a trendy platform nowadays)
> but there it improves performance and
> code size a bit so it is worth doing

By the way, part of the reason I think we should make the change where
it doesn't hurt (and probably helps) accuracy is so we're not telling

"Yes, some math functions in musl are slower than glibc because we're
taking extra care to make sure they give you less-accurate results."


In practice it's very few that are slower. I think most will just go
from being 2-3 times as fast as glibc to 3-5 times as fast as glibc.


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.