>> Keith Thompson wrote:
<http://www.c-faq.com/fp/libm.html>
"Nelu" <ta********@gmail.com> writes: Do you know the history of the bug?
In article <ln************@nuthaus.mib.org>
Keith Thompson <ks***@mib.org> wrote:It's arguable whether it's actually a bug.
Indeed.
The math library is fairly large, and a lot of C program don't use it
(there's seldom much need for floating-point math in system code).
Back when systems were smaller and linkers were dumber, there was a
significant advantage in not including the math code in the standard
library; it made a lot of programs substantially smaller.
Although even by the mid-1980s this was not much of a reason.
These days, size is less of an issue (but still not insignificant),
and linkers *should* be able to load only the functions that are
actually called. (I'm actually not sure of the current state of the
art in linkers, and the existence of dynamic libraries probably
confuses things further.)
Dynamic libraries do make things different.
One of the important ways they make things different is that they
offer the opportunity to optimize the system at boot time.
Suppose, for instance, that you have a Celeron, or an Athlon, or
a Pentium4, or a PentiumPRO, or an x86-64, or any of the myriad
other implementations that everyone uses since nobody ever uses an
architecture other than the x86. :-) There are ways to implement
the math functions so that they will work on every one of these
machines -- but no matter which way(s) you pick, they will be
unnecessarily slow on *some* of them, but very fast on some other(s).
Ideally, what you would like to have is a system in which the
math routines are chosen based on the CPU.
The CPU is, of course, fixed at boot time (you must power down the
machine to replace it). So, why not build 37 (or however many it
takes) *different* math libraries, each one optimal for one particular
implementation, and have the boot process choose the correct one?
To do this, of course, we have to have some code at boot time that
picks out the right library. This code will not do any math itself,
but -- if we write it in C -- will need the *rest* of the C library
(or some substantial portion thereof). So this works best if the
math library is a separate library, that can be installed during the
boot process by a program that uses the C library but not the math
library.
The actual benefit is pretty small on the x86 family, but can be
enormous on those other architectures that no one ever uses. In
particular, systems where floating-point hardware is optional will
often want to have a "software-only" math library and a "hardware-
based" math library.
(As it happens, various *other* functions, including those one would
want in the library used by the boot-time library-selection program,
are included in the set one might want to have swapped about. So
this can work even better if one can arrange to have multiple versions
of the entire C runtime libraries, math or not; but separating out
the libm section is easier and gets most of the performance in some
important cases.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it
http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
