Re: Optimized compiling with CPML problem
On Fri, 2 Apr 1999, nshimizu wrote:
> I am evaluating the CPML under the Debian/slink on EB164.
> I ususaly does not include <cpml.h> for stable results but <math.h>.
To use libcpml.a, you probably should include cpml.h because it maps the
appropriate calls to the fast calls in libcpml.a. I'm also evaluating
this lib, but under a potato system.
> I found that when I use "atan" with optimize option
> the link will cause a problem.
> The linker claims that there is no __atan2 entry.
There isn't such an animal in libcpml.a, fyi. That would explain the
missing entry, at least not in my "findings" so far. Read on...
> I checked the /usr/include/math.h and found
>
> -----------------------------------------------------------------------
> /* Get machine-dependent inline versions (if there are any). */
.....
> atan (double __x)
> {
> extern double __atan2 (double, double);
> return __atan2 (__x, 1.0);
> }
> -----------------------------------------------------------------------
>
> Does anyone know why this definition is here only for __OPTIMIZE__?
Yes. From what I can gather (on my slink system at least, not true under
glibc 2.1), the __OPTIMIZE__ is telling libm to include it's
machine-dependent inline functions rather than the standard algorythms
that are compiled on every machine. It's assumed that the inlines are
faster than the standard since the inlines are often written specifically
for the target machine arch. It's only included when __OPTIMIZE__ is used
since it's usually also assumed that you would want speed improvements if
you chose to optimise, thus, it goes for what it considers to be the
fastest routines for atan2, in this case, the inlines. If you look
elsewhere in __math.h for fabs() and copysign() defs, you'll notice that
those are all inline functions. __atan2() isn't really, but it is an
Alpha-optimised version of atan2() (poorly optimised in comparison to
glibc 2.1's, but still better than the standard algorythm).
> I think it does not help much even with libm or libffm. And I want
> to remove the definition. For my machine I will remove it immediately.
I wouldn't do that unless you intend on using libffm or libcpml
exclusively (or just want the plain ol' routines in libm without the
inlines). You may be better off to just remove or comment out the
__atan2() def from __math.h since you may want to keep the inlines for
fabs() and copysign(). That will keep atan2() from being mapped to
__atan2() and will subsequently work with libffm or libcpml using <math.h>
My pleasure.
What are you using for benchmarks when evaluating libcpml? I am using
clinpack, which is less than optimal, but it works. I can send results if
needed.
C
Reply to: