libm

[Rudi Chiarito]

Hello,
I have a couple of questions that maybe someone can help with. Exhibit A
is an x86_64 FC3 system:

# objdump -p /usr/lib64/libfftw.so | grep -A20 Version
Version References:
  required from libm.so.6:
    0x09691a75 0x00 03 GLIBC_2.2.5
  required from libc.so.6:
    0x0d696913 0x00 04 GLIBC_2.3
    0x09691a75 0x00 02 GLIBC_2.2.5
# rpm -qi fftw | grep ^[VRI]
Version     : 2.1.5                             Vendor: (none)
Release     : 5                             Build Date: Tue 14 Dec 2004
06:56:25 PM CST
Install Date: Wed 23 Mar 2005 04:14:50 PM CST      Build Host:
extras64.linux.duke.edu

Exhibit B is an x86_64 FC5 system:

# objdump -p /usr/lib64/libfftw.so | grep -A20 Version
Version References:
  required from libc.so.6:
    0x0d696913 0x00 05 GLIBC_2.3
    0x0d696914 0x00 04 GLIBC_2.4
    0x09691a75 0x00 03 GLIBC_2.2.5
    0x09691974 0x00 02 GLIBC_2.3.4

# rpm -qi fftw2 | grep ^[VRI]
Version     : 2.1.5                             Vendor: (none)
Release     : 12.fc5                        Build Date: Sat 18 Feb 2006
04:08:15 AM CST
Install Date: Wed 26 Apr 2006 05:00:30 PM CDT      Build Host:
hammer2.fedora.redhat.com

The FC3 fftw references libm, the FC5 one doesn't. Is one of the two
behaviours considered more proper? Scons' autoconf-like test fails with
the FC5 libfftw because it can't resolve sin() and cos(). The FC3
libfftw seems to reference those, too, but the reference to libm takes
care of that.

More in general, though, isn't a call to sin() and cos() expensive and
shouldn't the compiler just use inline native FP code? In the case of
FFTW those two are only used in the setup stages, with the actual FFTs
implemented with multiplications and additions (gcc uses SSE as
expected on x86_64), but not all code is going to be like that. Are
there reasons for them not to be inlined?

Thanks.

-- 
Rudi

[Callum Lerwick]

On Thu, 2006-04-27 at 18:42 +0200, Rudi Chiarito wrote:
>  More in general, though, isn't a call to sin() and cos()
> expensive and
>  shouldn't the compiler just use inline native FP code? In the case of
>  FFTW those two are only used in the setup stages, with the actual FFTs
>  implemented with multiplications and additions (gcc uses SSE as
>  expected on x86_64), but not all code is going to be like that. Are
>  there reasons for them not to be inlined? 
Isn't this what --ffast-math does?

Some gritty details seem to be here:

http://gcc.gnu.org/wiki/Math%20Optimization%20Flags

gcc is far smarter than many seem to realize. Sometimes far too smart...

[Rudi Chiarito]

On Thu, Apr 27, 2006 at 06:42:47PM +0200, Rudi Chiarito wrote:
>  Hello,
>  I have a couple of questions that maybe someone can help with. Exhibit A
>  is an x86_64 FC3 system:
>  
>  # objdump -p /usr/lib64/libfftw.so | grep -A20 Version
>  Version References:
>    required from libm.so.6:
>      0x09691a75 0x00 03 GLIBC_2.2.5 
[...]
>  # objdump -p /usr/lib64/libfftw.so | grep -A20 Version
>  Version References: 
[...]

Almost three months later, I have come across Exhibit C, fftw2 on a
i386 FC5 system (all three exhibits are official Extras packages):

# objdump -p /usr/lib/libfftw.so | grep -A20 Version
Version References:
[...]
  required from libm.so.6:
    0x0d696910 0x00 02 GLIBC_2.0

Is there a reason why under 32bit FC5 and 64bit FC3 the library
references libm, while it doesn't under 64bit FC5? It doesn't look like
the most predictable behaviour to me. Which of the two is considered
more proper?

-- 
Rudi

[Arjan van de Ven]

>  # objdump -p /usr/lib/libfftw.so | grep -A20 Version
>  Version References:
>  [...]
>    required from libm.so.6:
>      0x0d696910 0x00 02 GLIBC_2.0
>  
>  Is there a reason why under 32bit FC5 and 64bit FC3 the library
>  references libm, while it doesn't under 64bit FC5? It doesn't look like
>  the most predictable behaviour to me. Which of the two is considered
>  more proper? 

it's entirely possible that gcc on 64 bit has all the math operations
inlined, while on 32 bit a few are external (eg libm)..

[Rudi Chiarito]

On Tue, Jul 11, 2006 at 10:35:25PM +0200, Arjan van de Ven wrote:
>  it's entirely possible that gcc on 64 bit has all the math
> operations
>  inlined, while on 32 bit a few are external (eg libm).. 
Under FC5/x86_64:

# ldd -r /usr/lib64/libfftw.so.2
undefined symbol: cos   (/usr/lib64/libfftw.so.2)
undefined symbol: sin   (/usr/lib64/libfftw.so.2)
[...]

The libraries in the FC3/x86_64 package do reference libm properly.
That's the part that makes no sense to me and I can't see anything in
the spec files that might explain the two different behaviours.
Different includes, maybe?

-- 
Rudi

[José Abílio Matos]

On Tuesday 11 July 2006 21:51, Rudi Chiarito wrote:
>  Under FC5/x86_64:
>
>  # ldd -r /usr/lib64/libfftw.so.2
>  undefined symbol: cos   (/usr/lib64/libfftw.so.2)
>  undefined symbol: sin   (/usr/lib64/libfftw.so.2)
>  [...]
>
>  The libraries in the FC3/x86_64 package do reference libm properly.
>  That's the part that makes no sense to me and I can't see anything in
>  the spec files that might explain the two different behaviours.
>  Different includes, maybe? 
  For some reason your first message escaped my radar the first time.

  I am fftw2 packager and I am busy at the moment. If you find any fix for 
this I would like to hear to fix it.

  FWIW FC4/x86_64 has the same behaviour as FC5/x86_64.

-- 
José Abílio

[Callum Lerwick]

On Tue, 2006-07-11 at 22:02 +0200, Rudi Chiarito wrote:
>  Is there a reason why under 32bit FC5 and 64bit FC3 the library
>  references libm, while it doesn't under 64bit FC5? It doesn't look like
>  the most predictable behaviour to me. Which of the two is considered
>  more proper? 
Could this be compiler optimizations? GCC can replace libm calls with
inline assembly. Since x86_64 isn't saddled with i[345]86 compatibility
(3DNow, SSE and SSE2 are guaranteed to be available) it can do a lot
more of these optimizations than a generic i386 build can. Newer GCCs
might not even be bothering to link in libm if it has been able to
replace all calls with inline instructions.

Or maybe fftw itself is switching to x86_64 assembly. It appears recent
versions do have x86_64 assembly optimizations.