Hi Markus, Please find the attached patch against itpp-3.99.3.1.ebuild which provides the necessary updates for the first release candidate of the upcomming 4.0.0 stable release. The updated ebuild uses pkg-config mechanism for selecting blas and lapack libraries (available in the newest blas/lapack ebuilds prepared by Sebastien). BTW, there is one open issue not handled by the latest ebuild. The FFT/IFFT routines in IT++ can be provided by either FFTW or ACML or MKL. However, currently only FFTW works, because the necessary header files from ACML or MKL are not found during the IT++ configuration process. To make use of ACML or MKL FFT/IFFT support, we need some kind of mechanism to inform configure where "acml.h" and "mkl_dfti.h" are located, when available. Your ideas for solving this issue are welcome! Thanks! /Adam
Created attachment 132267 [details, diff] sci-libs/itpp-4.0.0_rc1.ebuild (version bump)
(In reply to comment #0) > FFT/IFFT support, we need some kind of mechanism to inform configure where > "acml.h" and "mkl_dfti.h" are located, when available. Your ideas for solving > this issue are welcome! Thanks a lot, Adam! Regarding fft: Could we pass the location via configure, e.g., -with-fftw-include=<include>, in addition to the already existing -with-fftw=<lib>? Thanks, Markus
(In reply to comment #2) > (In reply to comment #0) > > FFT/IFFT support, we need some kind of mechanism to inform configure where > > "acml.h" and "mkl_dfti.h" are located, when available. Your ideas for solving > > this issue are welcome! > > Thanks a lot, Adam! Regarding fft: Could we pass the location via > configure, e.g., -with-fftw-include=<include>, in addition to the > already existing -with-fftw=<lib>? Markus, Unfortunately, the current implementation does not have --with-fft-include switch. So far, I have been recommending to use CPPFLAGS for passing -I/path/to/include and LDFLAGS for -L/path/to/libs. Do you think it is more natural to have the accompanying --with-<feaure>-include switches for each configurable feature (module/library), rather than using CPPFLAGS for this purpose? If yes, I might add such a switch for the next release candidate of 4.0.0... /Adam
(In reply to comment #3) > Do you think it is more natural to have the accompanying > --with-<feaure>-include switches for each configurable feature > (module/library), rather than using CPPFLAGS for this purpose? If yes, I might > add such a switch for the next release candidate of 4.0.0... > I'd say that a "--with-<feaure>-include" switch is more natural since it is self-documenting (via configure --help), it clearly indicates that linking against X is supported, and configure really is the proper stage during building to setup the build environent. Appending things to C(PP)FLAGS seems more like a "hack" and is not as apparent to (not so experienced) users. Markus
(In reply to comment #4) > I'd say that a "--with-<feaure>-include" switch is more natural since > it is self-documenting (via configure --help), it clearly indicates that > linking against X is supported, and configure really is the > proper stage during building to setup the build environent. > Appending things to C(PP)FLAGS seems more like a "hack" and is not > as apparent to (not so experienced) users. OK. Then I will provide an additional --with-fft-include=DIR switch in itpp-4.0.0-rc2. However, I still do not see how it can be used in the ebuild to set ACML or MKL specific include directory. Could you shed some light on this? /Adam
(In reply to comment #5) > OK. Then I will provide an additional --with-fft-include=DIR switch in > itpp-4.0.0-rc2. However, I still do not see how it can be used in the ebuild to > set ACML or MKL specific include directory. Could you shed some light on this? Well, that's a whole different problem altogether and there's currently probably no clean way to do this. To do it properly, we probably had to introduce a virtual fft, an eselect fft mechanism, combined with pkg-config to get all the right includes/libs (just like for blas). Are there enough good other fft implementations around that would make such an endeavor worthwhile? Markus
(In reply to comment #6) > Well, that's a whole different problem altogether and there's > currently probably no clean way to do this. To do it properly, we > probably had to introduce a virtual fft, an eselect fft mechanism, > combined with pkg-config to get all the right includes/libs (just like > for blas). Are there enough good other fft implementations around that > would make such an endeavor worthwhile? I am not sure if a new fft virtual makes sense because FFT/IFFT routines from FFTW, MKL and ACML use completely different interfaces. They only provide the same functionality for IT++. So, the situation is similar to the ACML's CBLAS - it works more or less the same as the reference CBLAS, but their interfaces are different. As for the pros and cons of using AMD or Intel specific implementation of FFT on their CPUs instead of FFTW I do not have any performance results to present at the moment. But I might have a closer look at this issue. I have access to Core2Duo and AMD64 X2 platforms, both with 2GHz CPUs. /Adam
If we're dealing with different fft implementations for the itpp ebuild only we could add USE flags (such as "acml-fft" or whatever). I usually try to avoid USE flag clutter, but if there is a significant performance increase for some arches with specific fft implementations that may be ok. Then we could pass the proper libs/includes to itpp depending on which fft was requested via the configure switches. This way we can also make sure that the proper fft implementation is a dependency of itpp via "acml-fft? (" in DEPEND . Out current setup is probably broken anyway now that I think about it: the line "fftw? ( ||" assumes that all listed fft implementations are equivalent which they aren't since the libs probably differ in their names as well as locations. Thanks, Markus
Hi Adam, I just committed the ebuild for 4.0.0-rc2. I haven't added the pkg-config pieces yet, mainly because the *-atlas ebuilds in portage (3.7.34) don't provide the pkgconfig mechanism yet. Hopefully I can bump the atlas ebuilds soon to take care of this. Thanks, Markus
(In reply to comment #9) > I just committed the ebuild for 4.0.0-rc2. I haven't added the > pkg-config pieces yet, mainly because the *-atlas ebuilds in > portage (3.7.34) don't provide the pkgconfig mechanism yet. > Hopefully I can bump the atlas ebuilds soon to take care of this. IT++ 4.0.0 final is out, so you can bump the ebuild and change it to pkgconfig mechanism. BTW, you can remove itpp-3.10.10 ebuild, since 3.10.12 is fully stable. Should we try to ask other arch teams (e.g. alpha, hppa, ia64) to try IT++ out and keyword it? BR, /Adam
Hi Adam, Thanks much for the note! I'll try to do this asap. We can definitely try to get ia64, hppa and alpha on board. I'll file a bug once 4.0 is in the tree. Thanks, Markus
(In reply to comment #11) > Thanks much for the note! I'll try to do this asap. > We can definitely try to get ia64, hppa and alpha > on board. I'll file a bug once 4.0 is in the tree. Thanks! BTW, we should change virtual/tetex to virtual/latex-base in all itpp ebuilds. See bug #195894 for more details. BR, /Adam
