
Date: Mon, 23 Jan 2012 17:41:52 +0100 From: Szabolcs Nagy <nsz@...t70.net> To: musl@...ts.openwall.com Subject: libm i've looked into libm implementations to figure out what's best for musl some resources: http://nsz.repo.hu/libm.txt there are various issues: * reproducible semantics: linux uses double extended precision by default on i386 which does not give the same results as standard 64bit ieee754 (sse2, x86_64, arm) bsd uses plain double precision by default on i386 (so at least when bsd functions are ported the precision claims should be reevaluated) most of the recent advances in efficient and correct function evaluation assume strict ieee754 64bit arithmetics (so they can do formal proofs etc, some algorithms assume fma instruction which is not available on musl's targets) portable semantics are not easy to guarantee (extended precision, rounding modes, compiler optimizations) (especially if efficiency is important as well) * tradeoffs: modern libms (libmcr, libultim, crlibm) try to guarantee correctness but arg reduction and faithful (or even correct) rounding is hard to do and hard to verify some libms prefer simple implementation (eg the go math package sincos is from cephes and starts to get inaccurate when x > 2^30, but the implementation is much simpler than the arg reduction in fdlibm) in theory one should prefer correctness instead of size and speed, but there are significant differences in code size and implementation effort the speed of a correct implementation can be good in average case, but not in worstcase * libms in practice: many functions are the same in glibc and the various bsd libcs (they are mostly based on fdlibm, but glibc 64bit double precision functions are from the gpl licensed libultim) the extended precision algorithms are reused across different libcs as well, but there are 80bit vs 128bit differences. the correctness of extended precision algorithms are much less studied (eg there are no correctly rounded versions or worstcases for 2pi arg reductions) most of the complex functions are simple once elementary functions are there (bsd libcs has bsd licensed implementations of these) conclusion: the simplest approach for musl at this point is to reuse the already available math functions (+run the available tests on them) this can be done by diffing the various bsd and glibc functions and choosing the best one (usually they are the same except code organization and bit manipulation details) most of the task is understanding floating point semantics well (not the mathematics of the algorithms) and doing code cleanups code and ideas from crlibm might be possible to use but that would take much more effort and knowledge (assuming we want small code size) designing new algorithms for elementary functions seems to require a huge effort and the best tradoffs are not even clear
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.