-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Installation on Fedora 28 #121
Comments
It compiled and tests passed with
Single precision seems to be needed. |
May be helpful to indicate example configuration files are in share/gearshifft |
thanks for your feedback, I will look into the build process given your specs next days. using Precisions = List<float, double>; the fftw and fftwf backend is loaded. As fftw+fftwf build process can be error-prone, an option for a specific precision could be nice-to-have. |
I could reproduce this issue and updated the CMake config in the PR #122 . The README has been updated as well, and indicates the FFT extent configuration files. However, the program cannot know about that location, which can be changed after installing gearshifft with custom install prefix for the configuration files. |
Thanks for updated installation guides, may want compilation flags for FFTW to be included in submissions as optional further information. Might you expect to allow for interoperability with Fortran FFT libraries, for example Ooura FFT, FFTE, fftpack, pfft KISS FFT or Glassman FFT ? Any suggestions for clFFT and hcFFT - one issue here might be clang and gcc interoperability. |
clfft and hcfft/rocfft are on our radar. We indeed didn't look to much
yet into the fortran libraries as nobody around us uses them. Let's keep
in mind how to propagate library flags. Btw, can you give an example for
those?
|
Ok. Got clfft version to build. Main steps I followed: |
Examples of flags
./configure CC=/usr/bin/clang --enable-static --enable-shared --enable-avx2 --enable-sse2 --prefix=/home/benson/projects/gearshifft/fftw-3.3.8-clang-install --disable-fortran |
thanks for all the config information, I look into this next days. I am only familiar with cuFFT, clFFT and FFTW so far. I also tested FFTW flags two years ago (--enable-avx2, --enable-sse2, ..) and ended up with a single |
I am planning on testing rocFFT or hcFFT soon. I need to upgrade my rocm
installation first and I only have an 'oldish' R9 Nano. But it should be
enough for getting the hang of the software. I am in contact with an ARM
integrator, but have had no success yet to get my hands on a system.
I personally agree to look into configuration issues. However, including
that in the results file is tricky, we would have to forward this
information from cmake into the code (which is possible), but I am
wondering how easy it is to get the configure flags from any given fft
library into cmake??? For now, a note in a dedicated README.md appears
most feasible to me.
|
Reproducibility is a big issue in high performance computing. Any progress on this would be great. The following may be relevant: |
We know of the 2 software packages you mentioned. gearshifft is already
on spack:
```
$ ./bin/spack list gearshifft
==> 1 packages.
gearshifft
```
I am not sure we should support popper from within gearshifft. I was
just saying that inferring the build flags from external libraries
either from the gearshifft c++ code or the cmake build system is far
from trivial. Libraries come with all variants of reproducibility
support : from none to a libname_config to internal variables which
yield a string with the configure flags.
|
Added a README.md here Still not fully reproducible, but hopefully enough. Let me know what further information would be helpful. Expect to add a few more results on AMD hardware. |
Making FFTW optional would be great. Adding a simple default C/Fortran library that does not require a lengthy installation procedure would be very helpful, even if one can only compare FFTs for a few transform sizes. |
Which C/Fortran library would you suggest?
|
AMD hardware would be helpful to have. I only have access to a Ryzen
Threadripper as of recently. But I think EPYC measurements would be
lovely to have ... not to speak of VEGA numbers under ROCm. Volunteers?
|
Kiss FFT, FFTE, Glassman FFT or Ooura's FFT routines. What do you want the default to provide? Rough accuracy test for a variety of problem sizes? Are factors of 2,3,5 and 7 enough? Is comparison to 1D enough, or are 2D and 3D also helpful? For default, probably a C/C++ code is best. One can also add option of measuring Fortran codes, but think this should be optional to minimize setup complexity. |
I am completely open to other FFT libraries. It should be at least an FFT library, which is used by the community. I cannot estimate about this on the libraries mentioned above. I also thought about the installation procedure, which could be automatized via cmake routines. The user could select between an already installed FFTW or the automatic installation during the make process. Files are downloaded and build into a directory |
@psteinb I can play around with a vega64 GPU, but not sure, when time allows it. Btw, it might be a simple task, to include ROCm's rocFFT, as there is a HIP interface. So just some copy and renaming of the cufft routines, and it should go :) Then we also could see, if rocFFT/ROCm is producing correct results ;)No access to EPYC platform though. |
The benchmark code is nice and simple, so with an embedded FFT routine, compilation could be done with a simple makefile - this would allow for compile and run without much configuration. Not ideal for speed, but would greatly enhance adoption. Great on vega64 GPU. clFFT and MESA-OpenCL on Fedora 28 seems to work, though am getting a few accuracy errors on a Polaris GPU. |
Boost is mandatory for gearshifft, but it can also be part of the cmake install routine, if it cannot be found on the system. At the moment I would tend to provide a separate cmake based setup of FFTW to allow a test scenario, that is independent of installed FFT libs. This includes a test case, where gearshifft is not involved. This is already implemented, see here. |
Boost is used mostly to check precision, for which one can write a simple wrapper that gives most of the functionality and have reduced error reporting - as an example clFFT can use googletest and FFTW to verify correctness, but one need not install these to get clFFT to work. The netlib blas and lapack routines require a fortran compiler that is relatively close to the standard to be installed and run tests. This makes it easy to get a basic but not optimal installation working. It would also be helpful for tolerance for errors in fft to vary with precision, usually expect close to machine precision for exact FFT routines - at the moment the default is 4 digits, which is ok for half precision, but will not give warnings for single and double precision. |
Accuracy errors on Polaris GPU are from certain transforms not being implemented in clFFT. Those that are implemented seem to pass. Seems like there is some FFT implementation to do. |
I have troubles to understand, what do you want to test or what do you
The basic installation for gearshifft covers at least a C++14 compiler,
The precision can be configured via cmake. |
To collect data and compare different implementations, it is nice to have a reproducible setup. This includes: |
I will think about it, but Boost as dependency will remain. Have you experiences with embedded devices and compiling code (+things like boost) for them? I will look for some numbers or issues about that, to estimate the limits. I thought Boost is modular enough even for such purposes. |
It would be nice if it could run on an atmel atmega chip without too much modification, but expect this may be too much to ask. Making it easy to run on a phone with minor modifications would be great as well. |
Just had a look at this chip. It appears to be very powerful. What is
the application you are after? From the docs, I couldn't get out what
the development environment around it is. LLVM and sorts now also have
RISC backends, but I am unclear if people use this already in
production. If clang can build it, using boost shouldn't be a big deal.
But I am not an expert...just guessing here.
|
Hi,
Am trying to do an installation on a clean system with Fedora 28, GCC 8.1.1. Have installed cmake 3.10.3, boost 1.67 and fftw -3.3.8 (double precision, shared and static libraries). A makefile is generated by using cmake as follows:
After typing make I get the following:
Any suggestions?
The text was updated successfully, but these errors were encountered: