From owner-freebsd-ports Tue Jul 28 09:16:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA11529 for freebsd-ports-outgoing; Tue, 28 Jul 1998 09:16:51 -0700 (PDT) (envelope-from owner-freebsd-ports@FreeBSD.ORG) Received: from naur.cs.wvu.edu (naur.csee.wvu.edu [157.182.194.28]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA11496 for ; Tue, 28 Jul 1998 09:16:34 -0700 (PDT) (envelope-from dfrasnel@csee.wvu.edu) Received: (from dfrasnel@localhost) by naur.cs.wvu.edu (8.9.0/8.9.0) id MAA24187; Tue, 28 Jul 1998 12:13:57 -0400 (EDT) From: Daniel Frasnelli Message-Id: <199807281613.MAA24187@naur.cs.wvu.edu> Subject: Re: Ports category submission (fwd) To: dbader@eece.unm.edu (David A. Bader) Date: Tue, 28 Jul 1998 12:13:56 -0400 (EDT) Cc: ports@FreeBSD.ORG In-Reply-To: <199807281540.JAA18461@jalapeno.eece.unm.edu> from "David A. Bader" at "Jul 28, 98 09:40:43 am" X-Mailer: ELM [version 2.4ME+ PL15 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-ports@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I would include DSM, DFS, etc., as parallel computing tools, but I > certainly wouldn't call them a "true 'parallel cluster'". Actually, I was making the point that taken individually they do not constitute a parallel cluster (Yes, I agree with you), but a true parallel cluster features all of these facilities (DFS, DSM, etc.). My intention was more or less to present a project idea: Instead of implementing one or two features of clustering (message passing and/or shared memory) as (I believe) the Beowulf folks do, create an integrated parallel environment that is layered on Net/FreeBSD. > Many current supercomputers are logically equivalent to a cluster of > workstations with high speed interconnect, where tasks in a program > communicate by passing messages (e.g. MPI). Quite true. That which supercomputers do with high speed interconnect, a NOW does with ethernet cards. A layered environment would allow you to implement something like a hypercube topology not in hardware (as a CM5/SP3/etc.) but in a network-based NOW. Seamless integration of shared memory/node communication is easier to implement in hardware (for obvious reasons), but is more easily maintained with a high-level abstraction of hardware in software. Adding another computational node to the Origin2000 I work on is a greater hassle than plugging another PC into a hub :-) > In my research for high performance computing, I develop the most > efficient algorithms which dictate use of message passing, rather than > virtual shared memory, for performance. NP problems are mostly memory-bound (as data space and complexity increases) rather than bound by message passing efficiency, aren't they? (Not to say that message passing is insignificant!) > This category should be inclusive -- *ANY* tools (above > and beyond standard OS and networking infrastructure) which enable > multiple CPUs to cooperate together to solve a computational problem. I completely agree with you. Sorry if I gave an impression other than that! :-) Best regards, Daniel --- Daniel J. Frasnelli Imaging spectroscopy research (dfrasnel@wvu.edu) Remotely sensed data analyst Ecologist Extreme backpacker To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message