Chris@42
|
1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
Chris@42
|
2 <html>
|
Chris@42
|
3 <head><title>
|
Chris@42
|
4 FFTW FAQ - Section 2
|
Chris@42
|
5 </title>
|
Chris@42
|
6 <link rev="made" href="mailto:fftw@fftw.org">
|
Chris@42
|
7 <link rel="Contents" href="index.html">
|
Chris@42
|
8 <link rel="Start" href="index.html">
|
Chris@42
|
9 <link rel="Next" href="section3.html"><link rel="Previous" href="section1.html"><link rel="Bookmark" title="FFTW FAQ" href="index.html">
|
Chris@42
|
10 </head><body text="#000000" bgcolor="#FFFFFF"><h1>
|
Chris@42
|
11 FFTW FAQ - Section 2 <br>
|
Chris@42
|
12 Installing FFTW
|
Chris@42
|
13 </h1>
|
Chris@42
|
14
|
Chris@42
|
15 <ul>
|
Chris@42
|
16 <li><a href="#systems" rel=subdocument>Q2.1. Which systems does FFTW run on?</a>
|
Chris@42
|
17 <li><a href="#runOnWindows" rel=subdocument>Q2.2. Does FFTW run on Windows?</a>
|
Chris@42
|
18 <li><a href="#compilerCrashes" rel=subdocument>Q2.3. My compiler has trouble with FFTW.</a>
|
Chris@42
|
19 <li><a href="#solarisSucks" rel=subdocument>Q2.4. FFTW does not compile on Solaris, complaining about
|
Chris@42
|
20 <code>const</code>.</a>
|
Chris@42
|
21 <li><a href="#3dnow" rel=subdocument>Q2.5. What's the difference between <code>--enable-3dnow</code> and <code>--enable-k7</code>?</a>
|
Chris@42
|
22 <li><a href="#fma" rel=subdocument>Q2.6. What's the difference between the fma and the non-fma
|
Chris@42
|
23 versions?</a>
|
Chris@42
|
24 <li><a href="#languages" rel=subdocument>Q2.7. Which language is FFTW written in?</a>
|
Chris@42
|
25 <li><a href="#fortran" rel=subdocument>Q2.8. Can I call FFTW from Fortran?</a>
|
Chris@42
|
26 <li><a href="#cplusplus" rel=subdocument>Q2.9. Can I call FFTW from C++?</a>
|
Chris@42
|
27 <li><a href="#whynotfortran" rel=subdocument>Q2.10. Why isn't FFTW written in Fortran/C++?</a>
|
Chris@42
|
28 <li><a href="#singleprec" rel=subdocument>Q2.11. How do I compile FFTW to run in single precision?</a>
|
Chris@42
|
29 <li><a href="#64bitk7" rel=subdocument>Q2.12. --enable-k7 does not work on x86-64</a>
|
Chris@42
|
30 </ul><hr>
|
Chris@42
|
31
|
Chris@42
|
32 <h2><A name="systems">
|
Chris@42
|
33 Question 2.1. Which systems does FFTW run
|
Chris@42
|
34 on?
|
Chris@42
|
35 </A></h2>
|
Chris@42
|
36
|
Chris@42
|
37 FFTW is written in ANSI C, and should work on any system with a decent
|
Chris@42
|
38 C compiler. (See also <A href="#runOnWindows">Q2.2 `Does FFTW run on Windows?'</A>, <A href="#compilerCrashes">Q2.3 `My compiler has trouble with FFTW.'</A>.) FFTW can also take advantage of certain hardware-specific features,
|
Chris@42
|
39 such as cycle counters and SIMD instructions, but this is optional.
|
Chris@42
|
40
|
Chris@42
|
41 <h2><A name="runOnWindows">
|
Chris@42
|
42 Question 2.2. Does FFTW run on Windows?
|
Chris@42
|
43 </A></h2>
|
Chris@42
|
44
|
Chris@42
|
45 Yes, many people have reported successfully using FFTW on Windows with
|
Chris@42
|
46 various compilers. FFTW was not developed on Windows, but the source
|
Chris@42
|
47 code is essentially straight ANSI C. See also the
|
Chris@42
|
48 <A href="http://www.fftw.org/install/windows.html">FFTW Windows installation notes</A>, <A href="#compilerCrashes">Q2.3 `My compiler has trouble with FFTW.'</A>, and <A href="section3.html#vbetalia">Q3.18 `How do I call FFTW from the Microsoft language du
|
Chris@42
|
49 jour?'</A>.
|
Chris@42
|
50 <h2><A name="compilerCrashes">
|
Chris@42
|
51 Question 2.3. My compiler has trouble with
|
Chris@42
|
52 FFTW.
|
Chris@42
|
53 </A></h2>
|
Chris@42
|
54
|
Chris@42
|
55 Complain fiercely to the vendor of the compiler.
|
Chris@42
|
56
|
Chris@42
|
57 <p>
|
Chris@42
|
58 We have successfully used <code>gcc</code> 3.2.x on x86 and PPC, a recent Compaq C compiler for Alpha, version 6 of IBM's
|
Chris@42
|
59 <code>xlc</code> compiler for AIX, Intel's <code>icc</code> versions 5-7, and Sun WorkShop <code>cc</code> version 6.
|
Chris@42
|
60 <p>
|
Chris@42
|
61 FFTW is likely to push compilers to their limits, however, and several
|
Chris@42
|
62 compiler bugs have been exposed by FFTW. A partial list follows.
|
Chris@42
|
63
|
Chris@42
|
64 <p>
|
Chris@42
|
65 <code>gcc</code> 2.95.x for Solaris/SPARC produces incorrect code for
|
Chris@42
|
66 the test program (workaround: recompile the
|
Chris@42
|
67 <code>libbench2</code> directory with <code>-O2</code>).
|
Chris@42
|
68 <p>
|
Chris@42
|
69 NetBSD/macppc 1.6 comes with a <code>gcc</code> version that also miscompiles the test program. (Please report a workaround if you know
|
Chris@42
|
70 one.)
|
Chris@42
|
71 <p>
|
Chris@42
|
72 <code>gcc</code> 3.2.3 for ARM reportedly crashes during compilation.
|
Chris@42
|
73 This bug is reportedly fixed in later versions of
|
Chris@42
|
74 <code>gcc</code>.
|
Chris@42
|
75 <p>
|
Chris@42
|
76 Versions 8.0 and 8.1 of Intel's <code>icc</code> falsely claim to be <code>gcc</code>, so you should specify <code>CC="icc -no-gcc"</code>; this is automatic in FFTW 3.1. <code>icc-8.0.066</code> reportely produces incorrect code for FFTW 2.1.5, but is fixed in version 8.1.
|
Chris@42
|
77 <code>icc-7.1</code> compiler build 20030402Z appears to produce
|
Chris@42
|
78 incorrect dependencies, causing the compilation to fail.
|
Chris@42
|
79 <code>icc-7.1</code> build 20030307Z appears to work fine. (Use
|
Chris@42
|
80 <code>icc -V</code> to check which build you have.) As of 2003/04/18,
|
Chris@42
|
81 build 20030402Z appears not to be available any longer on Intel's
|
Chris@42
|
82 website, whereas the older build 20030307Z is available.
|
Chris@42
|
83
|
Chris@42
|
84 <p>
|
Chris@42
|
85 <code>ranlib</code> of GNU <code>binutils</code> 2.9.1 on Irix has been observed to corrupt the FFTW libraries, causing a link failure when
|
Chris@42
|
86 FFTW is compiled. Since <code>ranlib</code> is completely superfluous on Irix, we suggest deleting it from your system and replacing it with
|
Chris@42
|
87 a symbolic link to <code>/bin/echo</code>.
|
Chris@42
|
88 <p>
|
Chris@42
|
89 If support for SIMD instructions is enabled in FFTW, further compiler
|
Chris@42
|
90 problems may appear:
|
Chris@42
|
91 <p>
|
Chris@42
|
92 <code>gcc</code> 3.4.[0123] for x86 produces incorrect SSE2 code for
|
Chris@42
|
93 FFTW when <code>-O2</code> (the best choice for FFTW) is used, causing
|
Chris@42
|
94 FFTW to crash (<code>make check</code> crashes). This bug is fixed in <code>gcc</code> 3.4.4. On x86_64 (amd64/em64t), <code>gcc</code> 3.4.4 reportedly still has a similar problem, but this is fixed as of
|
Chris@42
|
95 <code>gcc</code> 3.4.6.
|
Chris@42
|
96 <p>
|
Chris@42
|
97 <code>gcc-3.2</code> for x86 produces incorrect SIMD code if
|
Chris@42
|
98 <code>-O3</code> is used. The same compiler produces incorrect SIMD
|
Chris@42
|
99 code if no optimization is used, too. When using
|
Chris@42
|
100 <code>gcc-3.2</code>, it is a good idea not to change the default
|
Chris@42
|
101 <code>CFLAGS</code> selected by the <code>configure</code> script.
|
Chris@42
|
102 <p>
|
Chris@42
|
103 Some 3.0.x and 3.1.x versions of <code>gcc</code> on <code>x86</code> may crash. <code>gcc</code> so-called 2.96 shipping with RedHat 7.3 crashes
|
Chris@42
|
104 when compiling SIMD code. In both cases, please upgrade to
|
Chris@42
|
105 <code>gcc-3.2</code> or later.
|
Chris@42
|
106 <p>
|
Chris@42
|
107 Intel's <code>icc</code> 6.0 misaligns SSE constants, but FFTW has a
|
Chris@42
|
108 workaround. <code>icc</code> 8.x fails to compile FFTW 3.0.x because it
|
Chris@42
|
109 falsely claims to be <code>gcc</code>; we believe this to be a bug in <code>icc</code>, but FFTW 3.1 has a workaround.
|
Chris@42
|
110 <p>
|
Chris@42
|
111 Visual C++ 2003 reportedly produces incorrect code for SSE/SSE2 when
|
Chris@42
|
112 compiling FFTW. This bug was reportedly fixed in VC++ 2005;
|
Chris@42
|
113 alternatively, you could switch to the Intel compiler. VC++ 6.0 also
|
Chris@42
|
114 reportedly produces incorrect code for the file
|
Chris@42
|
115 <code>reodft11e-r2hc-odd.c</code> unless optimizations are disabled for that file.
|
Chris@42
|
116 <p>
|
Chris@42
|
117 <code>gcc</code> 2.95 on MacOS X miscompiles AltiVec code (fixed in
|
Chris@42
|
118 later versions). <code>gcc</code> 3.2.x miscompiles AltiVec permutations, but FFTW has a workaround.
|
Chris@42
|
119 <code>gcc</code> 4.0.1 on MacOS for Intel crashes when compiling FFTW; a workaround is to
|
Chris@42
|
120 compile one file without optimization: <code>cd kernel; make CFLAGS=" " trig.lo</code>.
|
Chris@42
|
121 <p>
|
Chris@42
|
122 <code>gcc</code> 4.1.1 reportedly crashes when compiling FFTW for MIPS;
|
Chris@42
|
123 the workaround is to compile the file it crashes on
|
Chris@42
|
124 (<code>t2_64.c</code>) with a lower optimization level.
|
Chris@42
|
125 <p>
|
Chris@42
|
126 <code>gcc</code> versions 4.1.2 to 4.2.0 for x86 reportedly miscompile
|
Chris@42
|
127 FFTW 3.1's test program, causing <code>make check</code> to crash (<code>gcc</code> bug #26528). The bug was reportedly fixed in
|
Chris@42
|
128 <code>gcc</code> version 4.2.1 and later. A workaround is to compile
|
Chris@42
|
129 <code>libbench2/verify-lib.c</code> without optimization.
|
Chris@42
|
130 <h2><A name="solarisSucks">
|
Chris@42
|
131 Question 2.4. FFTW does not compile on Solaris, complaining about
|
Chris@42
|
132 <code>const</code>.
|
Chris@42
|
133 </A></h2>
|
Chris@42
|
134
|
Chris@42
|
135 We know that at least on Solaris 2.5.x with Sun's compilers 4.2 you
|
Chris@42
|
136 might get error messages from <code>make</code> such as
|
Chris@42
|
137 <p>
|
Chris@42
|
138 <code>"./fftw.h", line 88: warning: const is a keyword in ANSI
|
Chris@42
|
139 C</code>
|
Chris@42
|
140 <p>
|
Chris@42
|
141 This is the case when the <code>configure</code> script reports that <code>const</code> does not work:
|
Chris@42
|
142 <p>
|
Chris@42
|
143 <code>checking for working const... (cached) no</code>
|
Chris@42
|
144 <p>
|
Chris@42
|
145 You should be aware that Solaris comes with two compilers, namely,
|
Chris@42
|
146 <code>/opt/SUNWspro/SC4.2/bin/cc</code> and <code>/usr/ucb/cc</code>. The latter compiler is non-ANSI. Indeed, it is a perverse shell script
|
Chris@42
|
147 that calls the real compiler in non-ANSI mode. In order
|
Chris@42
|
148 to compile FFTW, change your path so that the right
|
Chris@42
|
149 <code>cc</code> is used.
|
Chris@42
|
150 <p>
|
Chris@42
|
151 To know whether your compiler is the right one, type
|
Chris@42
|
152 <code>cc -V</code>. If the compiler prints ``<code>ucbcc</code>'', as in
|
Chris@42
|
153 <p>
|
Chris@42
|
154 <code>ucbcc: WorkShop Compilers 4.2 30 Oct 1996 C
|
Chris@42
|
155 4.2</code>
|
Chris@42
|
156 <p>
|
Chris@42
|
157 then the compiler is wrong. The right message is something like
|
Chris@42
|
158
|
Chris@42
|
159 <p>
|
Chris@42
|
160 <code>cc: WorkShop Compilers 4.2 30 Oct 1996 C
|
Chris@42
|
161 4.2</code>
|
Chris@42
|
162 <h2><A name="3dnow">
|
Chris@42
|
163 Question 2.5. What's the difference between
|
Chris@42
|
164 <code>--enable-3dnow</code> and <code>--enable-k7</code>?
|
Chris@42
|
165 </A></h2>
|
Chris@42
|
166
|
Chris@42
|
167 <code>--enable-k7</code> enables 3DNow! instructions on K7 processors
|
Chris@42
|
168 (AMD Athlon and its variants). K7 support is provided by assembly
|
Chris@42
|
169 routines generated by a special purpose compiler.
|
Chris@42
|
170 As of fftw-3.2, --enable-k7 is no longer supported.
|
Chris@42
|
171
|
Chris@42
|
172 <p>
|
Chris@42
|
173 <code>--enable-3dnow</code> enables generic 3DNow! support using <code>gcc</code> builtin functions. This works on earlier AMD
|
Chris@42
|
174 processors, but it is not as fast as our special assembly routines.
|
Chris@42
|
175 As of fftw-3.1, --enable-3dnow is no longer supported.
|
Chris@42
|
176
|
Chris@42
|
177 <h2><A name="fma">
|
Chris@42
|
178 Question 2.6. What's the difference between the fma and the non-fma
|
Chris@42
|
179 versions?
|
Chris@42
|
180 </A></h2>
|
Chris@42
|
181
|
Chris@42
|
182 The fma version tries to exploit the fused multiply-add instructions
|
Chris@42
|
183 implemented in many processors such as PowerPC, ia-64, and MIPS. The
|
Chris@42
|
184 two FFTW packages are otherwise identical. In FFTW 3.1, the fma and
|
Chris@42
|
185 non-fma versions were merged together into a single package, and the
|
Chris@42
|
186 <code>configure</code> script attempts to automatically guess which
|
Chris@42
|
187 version to use.
|
Chris@42
|
188 <p>
|
Chris@42
|
189 The FFTW 3.1 <code>configure</code> script enables fma by default on PowerPC, Itanium, and PA-RISC, and disables it otherwise. You can
|
Chris@42
|
190 force one or the other by using the <code>--enable-fma</code> or <code>--disable-fma</code> flag for <code>configure</code>.
|
Chris@42
|
191 <p>
|
Chris@42
|
192 Definitely use fma if you have a PowerPC-based system with
|
Chris@42
|
193 <code>gcc</code> (or IBM <code>xlc</code>). This includes all GNU/Linux systems for PowerPC and the older PowerPC-based MacOS systems. Also
|
Chris@42
|
194 use it on PA-RISC and Itanium with the HP/UX compiler.
|
Chris@42
|
195
|
Chris@42
|
196 <p>
|
Chris@42
|
197 Definitely do not use the fma version if you have an ia-32 processor
|
Chris@42
|
198 (Intel, AMD, MacOS on Intel, etcetera).
|
Chris@42
|
199
|
Chris@42
|
200 <p>
|
Chris@42
|
201 For other architectures/compilers, the situation is not so clear. For
|
Chris@42
|
202 example, ia-64 has the fma instruction, but
|
Chris@42
|
203 <code>gcc-3.2</code> appears not to exploit it correctly. Other compilers may do the right thing,
|
Chris@42
|
204 but we have not tried them. Please send us your feedback so that we
|
Chris@42
|
205 can update this FAQ entry.
|
Chris@42
|
206 <h2><A name="languages">
|
Chris@42
|
207 Question 2.7. Which language is FFTW written
|
Chris@42
|
208 in?
|
Chris@42
|
209 </A></h2>
|
Chris@42
|
210
|
Chris@42
|
211 FFTW is written in ANSI C. Most of the code, however, was
|
Chris@42
|
212 automatically generated by a program called
|
Chris@42
|
213 <code>genfft</code>, written in the Objective Caml dialect of ML. You do not need to know ML or to
|
Chris@42
|
214 have an Objective Caml compiler in order to use FFTW.
|
Chris@42
|
215
|
Chris@42
|
216 <p>
|
Chris@42
|
217 <code>genfft</code> is provided with the FFTW sources, which means that
|
Chris@42
|
218 you can play with the code generator if you want. In this case, you
|
Chris@42
|
219 need a working Objective Caml system. Objective Caml is available
|
Chris@42
|
220 from <A href="http://caml.inria.fr">the Caml web page</A>.
|
Chris@42
|
221 <h2><A name="fortran">
|
Chris@42
|
222 Question 2.8. Can I call FFTW from Fortran?
|
Chris@42
|
223 </A></h2>
|
Chris@42
|
224
|
Chris@42
|
225 Yes, FFTW (versions 1.3 and higher) contains a Fortran-callable
|
Chris@42
|
226 interface, documented in the FFTW manual.
|
Chris@42
|
227
|
Chris@42
|
228 <p>
|
Chris@42
|
229 By default, FFTW configures its Fortran interface to work with the
|
Chris@42
|
230 first compiler it finds, e.g. <code>g77</code>. To configure for a different, incompatible Fortran compiler
|
Chris@42
|
231 <code>foobar</code>, use <code>./configure F77=foobar</code> when installing FFTW. (In the case of <code>g77</code>, however, FFTW 3.x also includes an extra set of
|
Chris@42
|
232 Fortran-callable routines with one less underscore at the end of
|
Chris@42
|
233 identifiers, which should cover most other Fortran compilers on Linux
|
Chris@42
|
234 at least.)
|
Chris@42
|
235 <h2><A name="cplusplus">
|
Chris@42
|
236 Question 2.9. Can I call FFTW from C++?
|
Chris@42
|
237 </A></h2>
|
Chris@42
|
238
|
Chris@42
|
239 Most definitely. FFTW should compile and/or link under any C++
|
Chris@42
|
240 compiler. Moreover, it is likely that the C++
|
Chris@42
|
241 <code><complex></code> template class is bit-compatible with FFTW's complex-number format
|
Chris@42
|
242 (see the FFTW manual for more details).
|
Chris@42
|
243
|
Chris@42
|
244 <h2><A name="whynotfortran">
|
Chris@42
|
245 Question 2.10. Why isn't FFTW written in
|
Chris@42
|
246 Fortran/C++?
|
Chris@42
|
247 </A></h2>
|
Chris@42
|
248
|
Chris@42
|
249 Because we don't like those languages, and neither approaches the
|
Chris@42
|
250 portability of C.
|
Chris@42
|
251 <h2><A name="singleprec">
|
Chris@42
|
252 Question 2.11. How do I compile FFTW to run in single
|
Chris@42
|
253 precision?
|
Chris@42
|
254 </A></h2>
|
Chris@42
|
255
|
Chris@42
|
256 On a Unix system: <code>configure --enable-float</code>. On a non-Unix system: edit <code>config.h</code> to <code>#define</code> the symbol <code>FFTW_SINGLE</code> (for FFTW 3.x). In both cases, you must then
|
Chris@42
|
257 recompile FFTW. In FFTW 3, all FFTW identifiers will then begin with
|
Chris@42
|
258 <code>fftwf_</code> instead of <code>fftw_</code>.
|
Chris@42
|
259 <h2><A name="64bitk7">
|
Chris@42
|
260 Question 2.12. --enable-k7 does not work on
|
Chris@42
|
261 x86-64
|
Chris@42
|
262 </A></h2>
|
Chris@42
|
263
|
Chris@42
|
264 Support for --enable-k7 was discontinued in fftw-3.2.
|
Chris@42
|
265
|
Chris@42
|
266 <p>
|
Chris@42
|
267 The fftw-3.1 release supports --enable-k7. This option only works on
|
Chris@42
|
268 32-bit x86 machines that implement 3DNow!, including the AMD Athlon
|
Chris@42
|
269 and the AMD Opteron in 32-bit mode. --enable-k7 does not work on AMD
|
Chris@42
|
270 Opteron in 64-bit mode. Use --enable-sse for x86-64 machines.
|
Chris@42
|
271
|
Chris@42
|
272 <p>
|
Chris@42
|
273 FFTW supports 3DNow! by means of assembly code generated by a
|
Chris@42
|
274 special-purpose compiler. It is hard to produce assembly code that
|
Chris@42
|
275 works in both 32-bit and 64-bit mode. <hr>
|
Chris@42
|
276 Next: <a href="section3.html" rel=precedes>Using FFTW</a>.<br>
|
Chris@42
|
277 Back: <a href="section1.html" rev=precedes>Introduction and General Information</a>.<br>
|
Chris@42
|
278 <a href="index.html" rev=subdocument>Return to contents</a>.<p>
|
Chris@42
|
279 <address>
|
Chris@42
|
280 <A href="http://www.fftw.org">Matteo Frigo and Steven G. Johnson</A> / <A href="mailto:fftw@fftw.org">fftw@fftw.org</A>
|
Chris@42
|
281 - 30 July 2016
|
Chris@42
|
282 </address><br>
|
Chris@42
|
283 Extracted from FFTW Frequently Asked Questions with Answers,
|
Chris@42
|
284 Copyright © 2016 Matteo Frigo and Massachusetts Institute of Technology.
|
Chris@42
|
285 </body></html>
|