Bugzilla Bug 194317

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 an attachment (id=132267) [edit]
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