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.
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...
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?
# 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)..
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?
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.
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.
devel@lists.stg.fedoraproject.org
-
Arjan van de Ven -
Callum Lerwick -
José Abílio Matos -
Rudi Chiarito