From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58530) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dnk4P-00077W-UZ for guix-patches@gnu.org; Fri, 01 Sep 2017 07:25:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dnk4L-0003mj-VC for guix-patches@gnu.org; Fri, 01 Sep 2017 07:25:05 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:58823) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dnk4L-0003md-RN for guix-patches@gnu.org; Fri, 01 Sep 2017 07:25:01 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dnk4L-0008FR-I3 for guix-patches@gnu.org; Fri, 01 Sep 2017 07:25:01 -0400 Subject: [bug#27905] changes for openmpi Resent-Message-ID: From: Dave Love References: <87zibja1of.fsf@i-ulialbion.it.manchester.ac.uk> <87h8x1t0op.fsf@gnu.org> <87d17mh20q.fsf@albion.it.manchester.ac.uk> <87fuc8w4lo.fsf@inria.fr> Date: Fri, 01 Sep 2017 12:24:30 +0100 In-Reply-To: <87fuc8w4lo.fsf@inria.fr> ("Ludovic \=\?iso-8859-1\?Q\?Court\=E8s\?\= \=\?iso-8859-1\?Q\?\=22's\?\= message of "Thu, 31 Aug 2017 09:58:43 +0200") Message-ID: <878thyzmoh.fsf@albion.it.manchester.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 27905@debbugs.gnu.org Ludovic Court=C3=A8s writes: > Hi Dave, > > Dave Love skribis: > >> Ludovic Court=C3=A8s writes: >> >>>> * mpi.scm (hwloc)[outputs]: Replace lib with nogui. >>>> (hwloc)[arguments]: Change configure --prefix; use "nogui" output, >>>> not "lib"; populate "all" output. >>>> (openmpi)[inputs]: Use hwloc-nogui. >>> >>> The downside of this is that the =E2=80=9Cnogui=E2=80=9D output is less= discoverable >>> (and it=E2=80=99s another user-visible breakage.) >> >> I don't think that's a problem, as people who want to avoid the GUI >> stuff will look for an alternative. >> >>> Also, it shouldn=E2=80=99t make any difference to the closure size of o= penmpi >>> anyway, no? >> >> No, but I think you should be able to run the hwloc programs on compute >> nodes without requiring X support, and you sometimes need to run openmpi >> programs specifically with openmpi (for memory affinity, for instance). > > OK so the gain over the current status (with the =E2=80=9Clib=E2=80=9D ou= tput) is that > people would be able to get, say, =E2=80=98hwloc-bind=E2=80=99, without g= etting the full > =E2=80=98lstopo=E2=80=99 and its dependencies, right? Right. > I guess that makes sense, though at the same time =E2=80=98lstopo=E2=80= =99 is probably > the most widely used program in hwloc. I'm surprised at that, since it's something you'd only normally run once on a node, and I'd normally only have the nogui variant on them anyhow. (You can dump the topology and display it separately if necessary, but the graphical output is often unwieldy on recent compute nodes -- or even not-so-recent ones.) > Perhaps we should keep the > current =E2=80=9Clib=E2=80=9D separation, and instead provide an =E2=80= =9Chwloc-minimal=E2=80=9D > package that does not depend on X11/Cairo? I've no strong feelings, but I'd still call it "nogui", or similar -- more descriptive. (Debian calls it -nox and Fedora has hwloc and hwloc-gui.) The no-GUI lstopo adds little to the closure. >>> > + (add-after 'install 'install-openmpi >>> > + (lambda* (#:key outputs #:allow-other-keys) >>> > + (let ((dest (format #f "~a/lib/valgrind" >>> > + (assoc-ref outputs "openmpi")))) >>> > + (mkdir-p dest) >>> > + (zero? >>> > + (system (format #f "mv ~a/lib/valgrind/libmpiwrap* ~= a" >>> > + (assoc-ref outputs "out") dest))))))= ))) >>>=20 >>> Why move it to a separate output? After all, we can keep it in =E2=80= =9Cout=E2=80=9D >>> since all it costs is the size of libmpiwrap.so, right? >> >> That would still pull in valgrind, which drags in a lot else (gdb, perl, >> python...). The support isn't commonly used as far as I can tell, and >> isn't configured by default -- I forgot about the performance hit >> . > > The hunk above is within Valgrind, so I don=E2=80=99t understand what you= mean > by =E2=80=9Cthat would still pull in valgrind.=E2=80=9D Sorry -- confused by the time lag. The rationale was that it either depends upon, or needs when it's used -- I can't remember -- the rest, which involves gdb's closure. I'm happy to drop libmpiwrap support anyhow, at least until another MPI might need it, if I was wrong that the openmpi built-in is a performance issue. Apologies for the misinformation and wasted time, though it was based on what's on the openmpi web site. > My suggestion was to: > > 1. Remove Valgrind from the inputs of Open MPI; > 2. Not add the =E2=80=98install-openmpi=E2=80=99 phase above to Valgrin= d. > > Does that make sense? > > Thank you, > Ludo=E2=80=99.