Kenneth, Adrian,
On 06/01/16 10:00, Kenneth Hoste wrote:
> Hi Adrian,
>
> On 31/05/16 13:38, Adrian Rodriguez Vilas wrote:
>> Hello,
>>
>> Until now I've managed to provide native compilation support. The
>> flags are passed correctly and the modules generated separately from
>> the rest.
>>
>> However, while I was working on this I realized that most of the
>> scientific software needs workarounds and hacks to be compiled for the
>> Xeon Phi. The most common (and less problematic) is adding the
>> "--host=x86-k1om-linux" option when compiling with configure/make,
>> this one is pretty simple.
>> In other cases (and not only one or two, I'm afraid) cross-compilation
>> is not supported by the program, or needs strange hacks that are
>> incredibly hard to automatize.
>>
>> In the end, this leaves only a few programs that can be compiled just
>> with the native support without expending some time with the
>> particular details of each app. So my question is: is this worth a PR?
>> It's interesting having this option knowing that most of the
>> compilations for the Phi will need extra work?
>>
>> I'm asking this because I don't think I can call it "Xeon Phi support"
>> knowing that only half the work is done. While the common part of the
>> Phi builds is included, it will require for developers to create
>> specific easyconfigs in every application desired.
> I think it would still be useful to provide support for building for
> Xeon Phi as good as we can on the EasyBuild side.
>
> It may not solve all the problems all the time, but it will alleviate
> some of them, and make things easier.
Not sure about that. Supporting cross-compilation properly can
be a whole lot of work. Just think about a library 'foo' which
provides a 'foo-config' command to retrieve flags & paths. The
former needs to be compiled for the Phi, while the latter needs
to be executable on the host. IMHO, this requires support in the
build system of the library itself.
Another question is how to present things to the user. On TACC's
Stampede, for example, the "papi" module provides two installations
of PAPI: one for the host in '<prefix>/x86_64' and one for the Phi
in '<prefix>/k1om'. The corresponding paths are provided via env
vars such as 'TACC_PAPI_INC' and 'MIC_TACC_PAPI_INC'.
Alternatively, one could argue that compiling for Phi uses a special
toolchain and thus ends up in a separate hierarchy when using a
hierarchical module naming scheme. But then there is software that
knows about Phi, e.g., Score-P or Scalasca. Building an installation
suitable for both the hosts and the Phi can easily be done by using
the Intel toolchain and playing around with 'configopts':
configopts = [
"--enable-shared --enable-platform-mic", # Phi build
"--enable-shared", # Host build
]
Some care is required when building the dependencies, but the above
is all that needs to be done in the Score-P/Scalasca easyconfigs.
The thing is that even the Phi build for us is a cross-compile build,
with some parts (e.g., measurement libraries) built for the Phi and
some parts (e.g., instrumenter and other tools) built for the host.
Therefore a Phi-only toolchain will pass in compiler flags that won't
make sense and cause a big mess.
(The second build compiles the measurement libs for the host, detects
the availability of the Phi build, and sets things up to do "the right
thing" automagically).
Markus
--
Dr. Markus Geimer
Juelich Supercomputing Centre
Institute for Advanced Simulation
Forschungszentrum Juelich GmbH
52425 Juelich, Germany
Phone: +49-2461-61-1773
Fax: +49-2461-61-6656
E-mail: [email protected]
WWW: http://www.fz-juelich.de/jsc/
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
