Build with Intel compilers

[olivhoenen]

Just quick report from early try (currently using Intel 19.0.4):

icpc  -Wall -pedantic -std=c++14 -I/cobra/u/olivh/muscle3/libmuscle/cpp/build/ymmsl/../../src -c /cobra/u/olivh/muscle3/libmuscle/cpp/build/ymmsl/../../src/ymmsl/settings.cpp -o /cobra/u/olivh/muscle3/libmuscle/cpp/build/ymmsl/objs/settings.o
In file included from /cobra/u/olivh/muscle3/libmuscle/cpp/build/ymmsl/../../src/ymmsl/settings.hpp(9),
                 from /cobra/u/olivh/muscle3/libmuscle/cpp/build/ymmsl/../../src/ymmsl/settings.cpp(1):
/cobra/u/olivh/muscle3/libmuscle/cpp/build/ymmsl/../../src/ymmsl/identity.hpp(112): error: name followed by "::" must be a class or namespace name
          friend ::std::size_t ::std::hash<::ymmsl::impl::Identifier>::operator()(
                        ^

In file included from /cobra/u/olivh/muscle3/libmuscle/cpp/build/ymmsl/../../src/ymmsl/settings.hpp(9),
                 from /cobra/u/olivh/muscle3/libmuscle/cpp/build/ymmsl/../../src/ymmsl/settings.cpp(1):
/cobra/u/olivh/muscle3/libmuscle/cpp/build/ymmsl/../../src/ymmsl/identity.hpp(112): error: expected an identifier
          friend ::std::size_t ::std::hash<::ymmsl::impl::Identifier>::operator()(
                                           ^

In file included from /cobra/u/olivh/muscle3/libmuscle/cpp/build/ymmsl/../../src/ymmsl/settings.hpp(9),
                 from /cobra/u/olivh/muscle3/libmuscle/cpp/build/ymmsl/../../src/ymmsl/settings.cpp(1):
/cobra/u/olivh/muscle3/libmuscle/cpp/build/ymmsl/../../src/ymmsl/identity.hpp(112): warning #320: invalid friend declaration
          friend ::std::size_t ::std::hash<::ymmsl::impl::Identifier>::operator()(
          ^

In file included from /cobra/u/olivh/muscle3/libmuscle/cpp/build/ymmsl/../../src/ymmsl/settings.hpp(9),
                 from /cobra/u/olivh/muscle3/libmuscle/cpp/build/ymmsl/../../src/ymmsl/settings.cpp(1):
/cobra/u/olivh/muscle3/libmuscle/cpp/build/ymmsl/../../src/ymmsl/identity.hpp(112): error: expected a ";"
          friend ::std::size_t ::std::hash<::ymmsl::impl::Identifier>::operator()(
                                           ^

[LourensVeen]

Does adding

#include <cstddef>

at the top of libmuscle/cpp/src/ymmsl/identity.hpp fix this?

[olivhoenen]

No it does not. When trying with another icpc (18.0.5) and after a distclean now it get some errors while compiling protobuf.

[LourensVeen]

Hmm, okay, so that needs work. I have access to a machine with the Intel toolchain installed, so I can have a go at it myself and see how far I get. It looks like there are people who compile protobuf using the Intel compiler, so it's probably just a bit of tweaking to the build system to make sure that settings are passed correctly to the dependency builds.

Does your model require the Intel compiler to build, or is this a nice-to-have optimisation?

[olivhoenen]

Not a requirement indeed, just nice to have as this is the go-to vendor in most our production systems.

[olivhoenen]

Just as additional piece of info, as I get (finally) back to muscle, there are also issues (in grpcio) while pip installing muscle-python on a platform where default compiler is INTEL (no show-stopper, will try to install and build our codes with GCC only, but for production cases this will need to be solved).

[LourensVeen]

Ah great, so now I get to figure out how to get Google's C++ back-end to grpcio to build correctly through pip using the Intel compiler...Ah well, could be fun :-). Thanks for reporting!

[LourensVeen]

I'm working a bit on this, and as I learn about the Intel tools and how they work, I wonder whether it's really necessary to compile libmuscle with the Intel toolchain, even if the model uses the Intel compiler? The Intel compiler claims to be compatible with gcc, which means one should be able to compile libmuscle using the GNU tools, and still compile the model with the Intel compiler and link against the GNU-built libmuscle shared library.

The Intel compiler generates faster compute code, but I'm not sure that it would make much of a difference on I/O, and even if it did, I/O via MUSCLE 3 is going to be only a small part of the total compute time anyway. Case in point, gRPC/Protobuf is very heavily optimised (because it ties much of Google together, and at that scale every cycle saved means a lower power bill) and doesn't even compile with the Intel toolchain.

I've got Protobuf fixed now, working on gRPC...

[olivhoenen]

This is very true, and we will happy to do the real case test. Nevertheless, note that in case your Fortran interface exposes some modules, this part at least will need to be built with Intel compiler as mod files are not compatible.

[LourensVeen]

Ah, that's a good point. I'm installing the .f03 file as well as the .mod though, so I think you should be able to compile that in using the Intel compiler, and then link against the GCC-compiled shared library, right? It's a plain C ABI, using the Fortran 2003 iso_c_bindings.

Getting gRPC to compile with the Intel compiler is not so easy it seems, so I'm going to work on some other things first. I think a note in the documentation about this will be good to have though, so I'm going to add that.

[LourensVeen]

Notes have been added for both C++ and Fortran. I'll keep this open until there's confirmation that submodels can be compiled with the Intel compiler and linked to a GNU-compiled libmuscle for both languages, that still needs testing.

[LourensVeen]

Released with 0.6.0, and reported working.