On Feb 28, 2006, at 7:45 PM, Durga Choudhury wrote:
When I downloaded openMPI and tried to compile it for our MIPS64
platform, it broke at 3 places.
I'm guessing since you call it MIPS64 that you aren't running IRIX,
since most SGI users just call it MIPS ;). We don't really support
the MIPS platform at this time, due to lack of resources. None of
the institutions involved in Open MPI have MIPS-based clusters, so it
hasn't been on our to-do list. If someone were to offer a temporary
guest account for a week or two, it would help immensely. Or, even
better, I'm happy to guide someone through cleaning up the port...
1. The configure script in the root directory did not have a case
for MIPS64. That is fixed in the attached patch.configure patch file.
Thanks. For future reference, configure is generated from a bunch
of .m4 macro files, so those are what need to be patched. The one in
this case is config/ompi_config_asm.m4. I've committed a patch for
this in our SVN trunk - it should be in the nightly tarballs tonight.
2. The Makefile.am in opal/asm/ directory is incorrect. It creates
a platform-dependent file called atomic-asm.s that has #include's
in it. According to gcc manual, .s assembly files are NOT
preprocessed and hence none of the macros in the atomic-asm.s file
were expanded.
Note that it works fine for IA32 platforms because that version of
atomic-asm.s file does not have macros in it. The patch.Makefile.am
fixes this. Note that you need to rerun automake after patching
this file.
Yes, the MIPS assembly is IRIX specific and (I believe) requires the
use of the SGI compilers. Using a capital S for the suffix isn't
really a fix, as some compilers we have to support don't like that
suffix (I can't remember offhand which, but there definitely are a
couple).
The right solution is to remove the short-cuts we took for the MIPS
assembly and make it like all the other platforms. This is unlikely
to happen within the OMPI development team unless someone provides us
with access to machines.
3. I don't remember the third place it broke right now. I can give
out a third patch later.
Now the question is: Is there a benchmark program I can run for the
openMPI suite of library? I tried NetPipe from Ameslab.gov. It
seems to run, but it terminates without producing any output,
either to the console or to any file. I tried specifying the output
file explicitly with the -o option, but to no avail.
NetPIPE should produce output to both standard output and a file
np.out. If it is failing to do so, you might want to check if it
started in the first place. I think some versions of NetPIPE get
unhappy unless you run with exactly two processes (mpirun -np 2 ./
NPmpi), but I could be mistaken there. If you aren't seeing the
output, there are some fairly serious issues with the Open MPI
build. First step would be to make sure the NetPIPE processes are
starting. Assuming they are, I would start them in a debugger,
something like:
mpirun -np 2 -d xterm -e gdb ./NPMpi
and see if they produce output that way (which would indicate that
there's a problem with our standard output forwarding). If they
produce no output, you might want to step through MPI_INIT and figure
out where they are getting hung up. If you can get some information
about where things are getting stuck, I can probably help with
narrowing down the issue.
By the way, if you are interested in continuing to work on getting
Open MPI ported to your platform, I'd recommend subscribing to the
devel mailing list - the discussions tend to get much more technical,
as we're less worried about boring a bunch of people who just want to
use Open MPI. The mailing list URL is:
http://www.open-mpi.org/community/lists/ompi.php
I'd also recommend working from a Subversion checkout of the trunk -
it's much easier to feed patches back (and they're much more likely
to be accepted) if you are working from the same source as all the
core developers. More information is available at this URL:
http://www.open-mpi.org/svn/
Good luck!
Brian
--
Brian Barrett
Open MPI developer
http://www.open-mpi.org/
