search

marcoheisig / cl-mpi

MPI bindings for Common Lisp with many useful extras
MIT License
65 stars 8 forks source link

compute MPI library version in Lisp #16

Closed stylewarning closed 6 years ago

stylewarning commented 6 years ago

This is a first commit attempting to simplify (or eliminate) the stub library.

It also contains a few other trivial simplifications (mostly deleted code).

marcoheisig commented 6 years ago

Thank you once again for contributing! I just merged your pull request.

You mentioned that you want to get rid of the cl-mpi-stub library. I absolutely agree. However, let me tell you why it is there, so that you don't have to repeat my painful mistakes:

The glorious, 800+ page MPI does not define how you can portably create an MPI application. Furthermore, the C data type of many MPI constants is not defined. In some implementations (OpenMPI), most constants are pointers to some structs, while in other implementations, they are preprocessor constants (MPICH). So for some implementations you need to grovel the constants, while for others you ask the dynamic linker. With the defgetter forms in the cl-mpi-stub.c, I can turn the former case into the latter.

However that does still not solve the problem of where to find the MPI libraries. Ideally, there would be a single libmpi.so that you could load dynamically. Instead, each MPI implementation uses a plethora of libraries and paths. The only somewhat portable mechanism to find all these dependencies is to call mpicc on a C file. So I use this mechanism to build the stub library that I can then load dynamically from Lisp. I fear that the alternative would be to maintain a curated list of well known library paths. I'm not sure how painful that would be in practice. Maybe you have a better idea.

stylewarning commented 6 years ago

@marcoheisig Yeah, I understand the problem and it's a tough one to solve. I was thinking about adding some patches to CFFI to allow these kinds of variables/symbols to be defined in the grovel file.

At minimum, this PR was to at least reduce the presence of the stub library.

As for library searching, some implementations, like SBCL, have options to re-search for the libraries upon start-up. (Specifically, the :dont-save option.) CFFI doesn't have an entry-point or a way to enable this.

My current goals are to get a version of my Lisp application built on a local Linux machine, and have it properly dynamically link to the available libraries at runtime. I certainly don't have the energy to put up with setting up a Lisp build environment on a whole cluster of machines, let alone one of the cluster machines.

I'm also looking into just packaging up all of the dynamic libraries that are used on the build machine for deployment on the target machine. I'm not yet sure how to go about that in a sane way.

guicho271828 commented 6 years ago

Hey, look up CFFI's wrapper feature. It is exactly there for such purpose. https://github.com/cffi/cffi/pull/121/commits/51348d57d74b97dbe3ea9fa6c3b091a87b3628f5

marcoheisig commented 6 years ago

@guicho271828 Thanks for pointing that out! That should solve the problem with the MPI constants. Nice!

@tarballs-are-good I did some brainstorming... maybe one could write a function GUESS-MPI-LIBRARIES, that returns a list of MPI library pathnames. For the guessing, one could first attempt to build the stub-library (which is otherwise not used anymore), invoke ldd on it and parse the results. If that fails, one could probe well-known file system locations. You then store the list of libraries in the Lisp image, such that MPI-INIT can dynamically load all these libraries each time. Of course, your cluster must have these in the same paths as your build node. But that is usually the case.