Make FFTS work on all architectures

[madscientist159]

I would like to use FFTS in a piece of FOSS engineering software, however that same software needs to operate on multiple different architectures including i386 and armel without NEON support. There should be an architecture-independent module added (probably written in C) that acts as a fallback to allow FFTS operation on architectures that don't support SSE, x86-64 registers, NEON, etc. There would be a significant performance penalty I know, but at least in my case operation in any form is better than not having FFT support at all on non-x86-64 architectures.

[RoyiAvital]

Does it work on Windows?

[JayKickliter]

@madscientist159 LiquidDSP was recently converted to MIT license. It has a very portable FFT implementation for when FFTW is not installed. you might be able to use that.

[linkotec]

@RoyiAvital FFTS work on all platform, https://github.com/linkotec/ffts

[pineking]

@linkotec https://github.com/linkotec/ffts , compile the code, and an error looks like:

/bin/bash ../libtool --tag=CC --mode=compile gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -g -O2 -MT ffts.lo -MD -MP -MF .deps/ffts.Tpo -c -o ffts.lo ffts.c libtool: compile: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -g -O2 -MT ffts.lo -MD -MP -MF .deps/ffts.Tpo -c ffts.c -o ffts.o ffts.c:34:18: fatal error: ffts.h: No such file or directory

include "ffts.h"

how to solve this error?

[linkotec]

@pineking It looks like you are trying to compile using Autoconf building, which is broken. Could you use CMake to build? It's portable way and simply like "mkdir build; cd build; cmake .. ; make"

[pineking]

@linkotec thank you, CMake seems works on x86_64. could you tell me how to build the armv7a library using CMake instead of build_android.sh? and does the linkotec/ffts support ARM64?

[linkotec]

Until now I have done all the building and testing natively; Windows x86 with MSVC and MinGW, Windows x86-64 with MSVC and MinGW, Linux x86 and x86-64 with various versions of GCC, Raspberry PI 1 Model B+ ARMv6+VFPv2 with no Neon support, and one other test board which has ARMv7+VFPv4 with Neon extensions.

ARM64 is supported like any other platform, but at the moment there is no optimized version for it. FFTS will fallback using normal C code, and performance depends on compiler.

If you cannot build natively, CMake supports cross compiling but I haven't had the time to look into this. There is another fork, which might help you, https://github.com/biotrump/ffts

[pineking]

@linkotec ,thank you, I will have a try . It is very interesting to me that ffts can be run on a hardware not support neon, such as Raspberry Pi as you mentioned, how about the performance with no Neon support? my application has huge computations, so the faster, the better.

[biotrump]

1. I can build for all NDK's platforms : https://github.com/biotrump/ffts-tec/tree/master-NDK but 64bit platforms fail to link cacheflush, so I disable dynamic code gen.
2. x86_64 : using neon, but I have not verified it.

[linkotec]

I haven't done any testing with NDK's but you could try disabling cacheflush as it's only purpose is to make sure that CPU ignores possible stale info in cache. And it's impossible for x86_64 to use NEON which is ARM only extension.

I would like to merge your changes, as Android is important target. Could you remove Fortran tests and place CMake toolchain files to "cmake" subfolder?

[biotrump]

https://github.com/biotrump/nufft I also integrate ffts into nufft, so you can use "ffte" or "ffts" or "netlib fft" to do nufft.

define ENG_FFTE (0)

define ENG_FFTS (1)

define ENG_FFTNL (2)

//setup fft engine type before nufft void nufftffte(int *id);

[madscientist159]

@linkotec your repository works reasonably well (with some modifications) but the AltiVec support seems broken. Lots of output like this:

macros.h:52:10: error: unknown type name ‘V4SF’

[linkotec]

AltiVec is broken because macros-altivec.h on line 42 has "typedef vector float V", which was renamed to V4SF for all other platforms.. I think the easiest fix is to disable inclusion by commenting out lines 45 and 46 in macros.h so that it will fall through to macros-alpha.h. I would like to know what other modifications you had to make, and if possible to include those to repo.

[madscientist159]

@linkotec Thanks, disabling AltiVec allowed build though I'd really like to see AltiVec reenabled for use on the OpenPOWER machines.

I created a pull request here: https://github.com/linkotec/ffts/pull/2

Note that the patches in that pull request may not be up to the project standards, but you can get a general idea of what needed to be fixed.

[aaronmswan]

@linkotec I was able to compile FFTS on Arm64 (Nvidia's Jetson TX2), but ffts_test fails with:

 Sign |      Size |     L2 Error
------+-----------+-------------
  -1  |         2 | 8.659561E-17
  -1  |         4 | 1.145552E-16
  -1  |         8 | 1.210162E-08
  -1  |        16 | 2.220916E-08
Illegal instruction (core dumped)

I started down the road of installing mono before I realized that arch/arm64 is not used. Any thoughts?

[linkotec]

You should try DISABLE_DYNAMIC_CODE=ON. Transforms smaller than 32 use static implementation, and your test failed when size was 32.

[aaronmswan]

That worked! Thanks for the quick reply. For reference, I compiled with

mkdir build
cd build
cmake -DDISABLE_DYNAMIC_CODE=ON ..
make

[madscientist159]

Note that the disabled dynamic code generation will slow thing down dramatically. We also need a ppc64[le] backend; support for old ARM and Intel/AMD insecure systems is not sufficient. :wink:

I've reenabled AltiVec here: https://github.com/madscientist159/ffts/commit/836b37426137b7f54d4eabd13426a3e81bcfb1d1