Yes, Fujitsu MPI is running on sparcv9-compatible CPU. Though we currently use only stable-series (v1.6, v1.8), they work fine.
Takahiro Kawashima, MPI development team, Fujitsu > Nathan, > > Fujitsu MPI is openmpi based and is running on their sparcv9 like proc. > > Cheers, > > Gilles > > On Friday, March 27, 2015, Nathan Hjelm <hje...@lanl.gov> wrote: > > > > > As a follow-on. How many of our supported architectures should we > > continue to support. The current supported list is: > > > > alpha > > amd64* > > arm* > > ia32* > > ia64 > > mips > > osx* > > powerpc* > > sparcv9 > > sync_builtin* > > > > * - known to be in-use. > > > > Additionally, should we continue to support the atomics in opal/asm? > > Some of those are known to be wrong and most compilers support in-line > > assembly. > > > > -Nathan > > > > On Thu, Mar 26, 2015 at 09:22:39AM -0600, Nathan Hjelm wrote: > > > > > > I am working on cleaning up the atomics in opal and I noticed something > > > odd. We define opal_atomic_sub_32 and opal_atomic_sub_64 yet only use > > > opal_atomic_sub_32 once: > > > > > > ./opal/runtime/opal_progress.c: val = > > opal_atomic_sub_32(&num_event_users, 1); > > > > > > This could easily be changed to: > > > > > > val = opal_atomic_add_32(&num_event_users, -1); > > > > > > And then we could remove all both opal_atomic_sub_32 and > > > opal_atomic_sub_64. Is there a reason to leave these functions in opal? > > > > > > > > > -Nathan
