From owner-freebsd-hpc@FreeBSD.ORG Tue Feb 14 05:28:54 2006 Return-Path: X-Original-To: freebsd-hpc@freebsd.org Delivered-To: freebsd-hpc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 92B6D16A420; Tue, 14 Feb 2006 05:28:54 +0000 (GMT) (envelope-from orac000@internet-mail.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 294E643D45; Tue, 14 Feb 2006 05:28:54 +0000 (GMT) (envelope-from orac000@internet-mail.org) Received: from frontend1.internal (mysql-sessions.internal [10.202.2.149]) by frontend1.messagingengine.com (Postfix) with ESMTP id 962E8D3427D; Tue, 14 Feb 2006 00:28:53 -0500 (EST) Received: from web3.messagingengine.com ([10.202.2.212]) by frontend1.internal (MEProxy); Tue, 14 Feb 2006 00:28:53 -0500 Received: by web3.messagingengine.com (Postfix, from userid 99) id 754FA25AB0; Tue, 14 Feb 2006 00:28:53 -0500 (EST) Message-Id: <1139894933.16845.254309588@webmail.messagingengine.com> X-Sasl-Enc: uLDuAxASl2Rdl8jj4gYfz3tiG1Z0GBE0RocwiEOa8orb 1139894933 From: "Aluminium Oxide" To: freebsd-hpc@freebsd.org, mpi-comments@mpi-forum.org Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 X-Mailer: MIME::Lite 5022 (F2.73; T1.15; A1.64; B3.05; Q3.03) Date: Tue, 14 Feb 2006 15:58:53 +1030 Cc: freebsd-current@freebsd.org Subject: HPC: Using Message Passing to distribute threads X-BeenThere: freebsd-hpc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "FreeBSD in High Performance Computing environments." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2006 05:28:54 -0000 Forgive me if I am suggesting that we reinvent the wheel, but I have a problem with a potentially simple solution. It concerns the difficulty of adapting an application to use a parallel computing system, such as with MPI or PVM. I would like help possible to write a simple (heh heh) compiler directive, or header, or a wrapper function which allows one to add a tag or wrap a function call to a function which will be called iteratively to spawn not just a new thread, but a new thread ***which can be passed to another node*** in a parallel computer system? This seems like a very simple and elegant method by which non-parallelised code can be adapted to a parallel architecture. My C, and my understanding of threading is very limited, and I've never written any kernel code. However, I will try and give an example: The adaption process would simply become o #include /* Add support for a parallel computing thread call */ o locate higher-level functions which are computationally intensive and will be called iteratively; o replace the raw function call with a pvmwrapped call. Eg., /*A module to calculate n! for the first 1000 numbers*/ int number; long double number_factorial; long double factorial (int number) {.....} ..... scanf("%d",number); for (i=0;i==number;i++,number_factorial=(factorial(number))) { printf ("%d factorial = %d",number_factorial; } .... would become #include int i,number; long double number_factorial; long double factorial (int number) {.....} ..... scanf("%d",number); for (i=0;i==number;i++,pvmwrap(number_factorial=(factorial(number)))) { printf ("%d factorial = %d",pvmwrap(factorial(number); } .... pvmwrap would have the necessary calls via the message passing protocol to create the thread on the next available node, rather than on the local system, and return the result to the caller. pvmwrap will need to perform type identification of the variables, or targets of pointers, and then declare these on the executing node first, to permit execution without having to specifically code these declarations as parallelised (which would greatly complicate the adaption to parallelism). The few cycles used to perform these type identifications each iteration are negligible compared with those of the wrapped function itself. What say ye? Damien Miller =================================== Sub POSIX lumen orac000@internet-mail.org +61 422 921 498 au.geocities.com/orac000000/bsd.html =================================== -- Aluminium Oxide orac000@internet-mail.org -- http://www.fastmail.fm - Choose from over 50 domains or use your own From owner-freebsd-hpc@FreeBSD.ORG Tue Feb 14 16:30:47 2006 Return-Path: X-Original-To: freebsd-hpc@freebsd.org Delivered-To: freebsd-hpc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C2EB16A43D for ; Tue, 14 Feb 2006 16:30:47 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3EBE843D49 for ; Tue, 14 Feb 2006 16:30:47 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id k1EGUkV9012627; Tue, 14 Feb 2006 08:30:46 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id k1EGUk6d012626; Tue, 14 Feb 2006 08:30:46 -0800 Date: Tue, 14 Feb 2006 08:30:46 -0800 From: Brooks Davis To: Aluminium Oxide Message-ID: <20060214163046.GA8572@odin.ac.hmc.edu> References: <1139894933.16845.254309588@webmail.messagingengine.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fUYQa+Pmc3FrFX/N" Content-Disposition: inline In-Reply-To: <1139894933.16845.254309588@webmail.messagingengine.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: freebsd-hpc@freebsd.org Subject: Re: HPC: Using Message Passing to distribute threads X-BeenThere: freebsd-hpc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "FreeBSD in High Performance Computing environments." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2006 16:30:47 -0000 --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [Dropped irrelevent mailing lists. In general CCing lists at multiple sites is bad form]. On Tue, Feb 14, 2006 at 03:58:53PM +1030, Aluminium Oxide wrote: > Forgive me if I am suggesting that we reinvent the wheel, but I have a > problem with a potentially simple solution. >=20 > It concerns the difficulty of adapting an application to use a parallel > computing system, such as with MPI or PVM. >=20 > I would like help possible to write a simple (heh heh) compiler > directive, or header, or a wrapper function which allows one to add a > tag or wrap a function call to a function which will be called > iteratively to spawn not just a new thread, but a new thread ***which > can be passed to another node*** in a parallel computer system? >=20 > This seems like a very simple and elegant method by which > non-parallelised code can be adapted to a parallel architecture. That you're describing is functionally if not syntatcicaly identical to OpenMP. http://en.wikipedia.org/wiki/OpenMP GCC's GOMP project is creating such a implementation for SMP systems at: http://savannah.nongnu.org/projects/gomp/ Note that this won't work for a cluster, there have been implementations of OpenMP on top of message passing libraries, but codes and clusters where such implementations make sense given the communication overhead are rare. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --fUYQa+Pmc3FrFX/N Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFD8gW0XY6L6fI4GtQRAmnCAKCNyUmlU59AhPlSmRTccEha9U4KYgCfSpAE 713XHA63388Q+R9GYKe66lg= =LW0v -----END PGP SIGNATURE----- --fUYQa+Pmc3FrFX/N--