HDTenEightyP/NetNews huggingface dataset:
From: matloff%toto.Berkeley.EDU@ucbvax.Berkeley.EDU (Norman Matloff)
Subject: revised MulSim multiprocessor simulator available by ftp
Organization: Div. of Computer Science, UC Davis
Date: 30 Dec 92 05:53:10 GMT

            ******************************************
            *                                        *
            *                                        *   
            *                                        *   
            *    MulSim Multiprocessor Simulator     *
            *                                        *   
            *           REVISED VERSION              *
            *                                        *   
            *          Available Via Ftp             *   
            *                                        *   
            *           cs.ucdavis.edu               *   
            *                                        *   
            *                                        *   
            *                                        *   
            ******************************************

                                                         
                                                         
I have made several improvements and extensions to the MulSim
multiprocessor simulator I posted here a few months ago, such as

   --  built-in memory-access functions list expanded to:

          bus; crossbar; snoopy-invalidate bus; snoopy-update bus

   --  on-line help facility added

   --  user documentation expanded

(A malloc error which showed up sometimes in the SPARC version has
also been fixed.)

In addition, I have now made the package available via anonymous ftp,
instead of e-mail, which was getting to be too cumbersome.  The ftp site
is cs.ucdavis.edu, in the directory pub/MulSim.

Please let me know if you have any questions or problems concerning
the package.

   Norm Matloff
   Division of Computer Science
   University of California at Davis
   Davis, CA  95616
   (916) 752-1953
   matloff@heather.cs.ucdavis.edu



Newsgroups: comp.parallel
From: sreedhar@cs.mcgill.ca (V.C. SREEDHAR)
Subject: (comp.lang.functional) tree of frames
Apparently-To: comp-parallel@ftp.uu.net
Keywords:  tree of frames ...
Organization: SOCS - Mcgill University, Montreal, Canada
Date: Tue, 22 Dec 1992 20:50:00 GMT

Hello:

I read in PRISC (Nikhil and Arvind) that they support 
tree of frame for function invocation.
In a stack model it is much simpler to manage the stack of
frames. For supporting tree of frames  one has to
allocate space from the heap. This could an expensive operation.
Also how does one manage the run time heap.
How does one compile programs to  support tree of frames.
In terms of storage space management, I find difficult to
understand  management of tree of frames (unlike
in stack based model,  which is simple to implement).

Thanks a lot


Sreedhar
From: lomow@jade.ab.ca (Greg Lomow)
Newsgroups: comp.parallel
Subject: Call for Papers
Date: 24 Dec 92 19:57:46 GMT
Organization: Clemson University
Return-Path: <lomow@jade.ab.ca>


			****    CALL FOR PAPERS    ****

		INTERNATIONAL JOURNAL OF COMPUTER SIMULATION

					is announcing a
					 SPECIAL ISSUE
					scheduled for 1994
						  on

	PRACTICAL, DISTRIBUTED AND PARALLEL SIMULATION
_____________________________________________________________

Computer simulation is being used to solve problems of 
increasing size and complexity over an ever expanding range 
of applications.  To meet these challenges, the simulations 
are often executed on multiple processor systems ranging from 
shared memory computers, to clusters of workstations, to 
distributed memory multiprocessors.

Papers are sought from practioners and researchers solving 
large-scale, practical simulation problems using multiple 
processor systems.  Papers should stress the practical 
aspects of the work, what is novel about the approach, how it 
expands the application and use of simulation, and the 
lessons learned from the projects.

Relevant types of simulation include, but are not limited to:

	SIMNET
	Training simulation
	Distributed Interactive Simulation

	Real time simulation
	Heterogenous computing systems
	Hardware-in-the-loop simulation

	Virtual reality
	Decision support systems

Relevant application areas include, but are not limited to:

	Communication systems
	Telecommunication systems
	Transportation systems
	Military systems
	Financial applications
	Environmental systems
	Computational biology, chemistry, and physics

Other relevant topics include synchronization methods, 
scalability, programming languages, performance studies, and 
visualization.
_____________________________________________________________

Interested authors are invited to contact the Guest Editor 
for more information and for manuscript guidelines.  Five 
copies of a compete manuscript are to be submitted to the 
Guest Editor by June 30th, 1993:

Dr. Greg Lomow, Guest Editor
Jade Simulations
2010 Corporate Ridge, Suite 700
McLean, Virginia  22102

Telephone:	703-749-1467
Facsimile:	703-749-1489
Email:		lomow@jade.ab.ca


Dr. George W. Zobrist, Editor
Department of Computer Science
University of Missouri-Rolla
Rolla, Missouri  65401
Telephone:	314-341-4836
Email:		c2816@umrvmb.umr.edu
_____________________________________________________________

Publisher:
Ablex Publishing Company
355 Chestnut Street
Norwood, NJ 07648
Newsgroups: comp.parallel
From: mellon@itd.nrl.navy.mil
Subject: Request for info: UNAS/SAILS
Organization: Clemson University
Date: Thu, 24 Dec 92 16:49:45 EST

I am looking for any information on a package called UNAS/SAILS (possibly out
of TRW).  It apparently is a product which allows tieing together several
applications into a single entity suitable for distributed execution.  

Nothing came up in a literature search (1988 to current): if anyone
has a pointer to an information source or experience with the product,
please forward to: mellon@jade.itd.nrl.navy.mil.  

	Thanks,

Larry Mellon
Jade Simulations (703) 749-1467


Newsgroups: comp.parallel
From: jf@edv6000.tuwien.ac.at (Josef Fritscher)
Subject: Re: PVM's rcvinfo() function.
Apparently-To: comp-parallel@news.uu.net
Reply-To: fritscher@email.tuwien.ac.at
Organization: Technical University of Vienna
Date: Tue, 22 Dec 1992 12:36:53 GMT

In article <1992Dec21.205055.23644@hubcap.clemson.edu>, pestep@convex.com (Pat Estep) writes:
|> In article <1992Dec21.132806.24272@hubcap.clemson.edu> <ruucp@samsung.com> writes:
|> >Hi;
|> >
|> >In the master program i a doing a >>>>putbytes(image, 262144);
|> >Then snd() to slave. In the slave when i do rcvinfo() it
|> >returns message size as 262152. (Possibly 2 ints).
|> >
|> >Can anyone explain this? I understand there will be padding/stripping
|> >at lower levels, but does it reflect at the user level? Do i have
|> >to strip off some headers etc?
|>   the moral to the story is that in pvm, you can't query to see what's
|>   in the incoming buffer or how much is in the buffer.  the receiving
|>   program has to know.
|> -- 
|> Pat Estep                               System Integration and Support
|> Convex Computer Corporation
|> 3000 Waterview Parkway                  Email: pestep@convex.com
|> Richardson, TX 75080                    Voice: (214) 497-4814
|> 

An alternative is, that the sender can inform the receiver, and that can
be done in the same message.

Just my simple $ 0.02 tip for Christmas

Joe
-- 
Josef Fritscher                     Internet: fritscher@edvz.tuwien.ac.at
Computing Center                      Bitnet: fritscher@awituw64.bitnet
Technical University of Vienna    in reality: jf@edv6000.tuwien.ac.at
Wiedner Hauptstrasse 8-10              Voice: ++431 58 801/5505
A-1040 Vienna, Austria/Europe		 Fax: ++431 58 74 211 
Member of the Austrian Center for Parallel Computation (ACPC)
-------------------------------------------------------------------------
The function of local-in-Universe critical information-gathering and
local-in-Universe problem-solving is manifest in the cockpit of all
great airplanes.                                  (R. Buckminster Fuller)

Newsgroups: comp.parallel
From: axk8773@usl.edu (Kalhan Ajay)
Subject: PVM's rcvinfo() function.
Apparently-To: rex!samsung!comp-parallel@samsung.com
Reply-To: <ruucp@samsung.com>
Organization: University of Southwestern Louisiana
Date: Mon, 21 Dec 1992 03:18:56 GMT

Hi;

In the master program i a doing a >>>>putbytes(image, 262144);
Then snd() to slave. In the slave when i do rcvinfo() it
returns message size as 262152. (Possibly 2 ints).

Can anyone explain this? I understand there will be padding/stripping
at lower levels, but does it reflect at the user level? Do i have
to strip off some headers etc?

Thanx in advance.

/ajay
email: kalhan@usl.edu

Newsgroups: comp.parallel
From: raj@mcs.kent.edu (S. Rajagopalan (Babu))
Newsgroups: comp.parallel
Subject: Info needed about Parallax and Parahna
Date: 26 Dec 92 01:45:37 GMT
Organization: Kent State University
Apparently-To: comp-parallel@uunet.uu.net


  I would like to know about systems for using idle processors to run programs.
  I guess Parallax and Parahna are such systems. 
   
  More info. regarding this is appreciated.

  Thanks in advance.

   srinivas
   raj@mcs.kent.edu
From: nikos@cs.cornell.EDU (Nikos P. Pitsianis)
Newsgroups: comp.parallel
Subject: CM Question: stencils in CM Fortran?
Keywords: stencil, CM Fortran, differential equations, discretization
Date: 27 Dec 92 22:35:37 GMT
Organization: Cornell University, CS Dept., Ithaca, NY

Hi Net,
Using gopher-WAIS I found the following document:

0000024TS   
910408
 (C) 1989 Thinking Machines Corp.  All rights reserved.
Chapter 4 :  4.3 Communicating in Parallel
4.3 Communicating in Parallel

... that says:

For solving differential equations, CM Fortran programs can  access  a  li-
brary  of stencil routines. These routines combine pipelined floating-point arithmetic with highly optimized  grid  communications,  often  in  several directions at once. The communication patterns are customized to the vari-
ous stencil, or star, patterns of the finite difference discretizations of these  equations. For example, the two-dimensional, five-point stencil routine gets data from four grid neighbors and performs  four  adds  and  five
multiplies; it achieves speeds considerably beyond those achieved by manual
coding of the same operations.


Where are those routines? How can I access them?

Please send any information you have on the subject.

Thank you,
-- Nikos
_____________________________________________________________________

  Nikos P Pitsianis                 Internet : nikos@cs.cornell.edu    
  Cornell University                   Phone : (607) 255 3042          
  4130 Upson Hall, Dept of Comp Sc       FAX : (607) 255 4428          
  Ithaca, NY 14853                      Home : (607) 257 3471
Newsgroups: comp.parallel
From: vwulpen@cs.kuleuven.ac.be (Henk Van Wulpen)
Subject: Re: Torus vs. Hypercube
Apparently-To: comp-parallel@belgium.eu.net
Organization: Dept. Computerwetenschappen
Date: Tue, 29 Dec 1992 18:58:21 GMT

In article <1992Dec27.201910.28352@ee.eng.ohio-state.edu>, bai@rainier.eng.ohio-state.edu (Baback A. Izadi) writes:
|> Couple of weeks ago, I think heard a speaker claiming that
|> 2-dimensional Torus and hypercube have basically the same
|> topology. How could this be true? If it is, can someone
|> point me to some references?
|> 
|> Thank you
|> 
|> Baback


In my opinion, this is only true for hypercube dimensions up to
four. It is fairly easy to construct tori that are completely
equivalent to a hypercube. Simply use the binary naming for the
nodes and take into account that each node should be directly
connected with all nodes at Hamming distance 1. What you get is :



0 D

			*
			  0     (smart, heh ? :))


1 D

		    - - *-------* - -
			  0	  1



2 D			|	|
		
		    - -	*-------* - -
			|10	|11
			|	|
			|	|
			|	|
	    	    - -	*-------* - -
			 00	 01
			|	| 



3 D		|	|	|	|

	    - -	*-------*-------*-------* - -
		|110	|010	|011	|111
		|	|	|	|
		|	|	|	|
		|	|	|	|
	    - -	*-------*-------*-------* - -
		 100	 000	 001	 101
		|	|	|	|



4 D

		|	|	|	|

	    - -	*-------*-------*-------* - -
		|1110	|1010	|1011	|1111
		|	|	|	|
		|	|	|	|
		|	|	|	|
	    - -	*-------*-------*-------* - -
		|0110	|0010	|0011	|0111
		|	|	|	|
		|	|	|	|
		|	|	|	|
	    - -	*-------*-------*-------* - -
		|0100	|0000	|0001	|0101
		|	|	|	|
		|	|	|	|
		|	|	|	|
	    - -	*-------*-------*-------* - -
		 1100	 1000	 1001	 1101
		|	|	|	|




Hope this was what you were looking for...

-Henk.


----------------------------------------------------------------------------
Henk Van Wulpen                     |   Money won't buy happiness,
Engineering and Computer Science    |   But at least I'll wear nice cloths
 senior at the K.U.Leuven, Belgium  |   When I'm depressed...
vwulpen@cs.kuleuven.ac.be           |                (T.M. Miller)
----------------------------------------------------------------------------
From: an1060@anon.penet.fi
Newsgroups: comp.parallel
Subject: Parallel Algorithms
Date: 26 Dec 92 18:18:02 GMT
Organization: Anonymous contact service
Apparently-To: comp-parallel@fuug.fi
X-Anonymously-To: comp.parallel

Hello,

I have the following book for sale:

Analysis & Design of Parallel Algorithms: Arithmetic & Matrix Problems
by Lakshmivarahan & Dhall, 1990.

It is in new condition (the binding will "crack" when opened)!!!

Publishers Price: $44....I ask: $35

Please respond to:  mantell@ams.sunysb.edu

Thanks

Abe

-------------------------------------------------------------------------
To find out more about the anon service, send mail to help@anon.penet.fi.
Due to the double-blind system, any replies to this message will be anonymized,
and an anonymous id will be allocated automatically. You have been warned.
Newsgroups: comp.parallel
From: tve@crackle.CS.Berkeley.EDU (Thorsten von Eicken)
Subject: Re: (comp.lang.functional) tree of frames
Keywords: tree of frames ...
Organization: University of California, Berkeley
Date: 24 Dec 1992 07:22:25 GMT

In article <1992Dec23.140907.21427@hubcap.clemson.edu> sreedhar@cs.mcgill.ca (V.C. SREEDHAR) writes:
>I read in PRISC (Nikhil and Arvind) that they support 
>tree of frame for function invocation.
>In a stack model it is much simpler to manage the stack of
>frames. For supporting tree of frames  one has to
>allocate space from the heap. This could an expensive operation.

Yes and no. Basically, instead of adding to or subtracting from the
stack pointer, you ``call malloc''. This is the simple but expensive
way. More realistically, you write your own memory allocator and inline
the typical case. Usually you'd choose a binned allocator, i.e., a
table of free lists per block size (good mallocs do that too). Notice
that the frame size is normally static, so you can generate the index
into the table at compile time. If you want, you can optimize the table
to only have entries for frame sizes that actually occur in the
program. The next optimization is to use ``stacklets'': small fixed
sized stacks which allow you to use stack allocation for one child
frame most of the time.  Haven't gotten around to implement that yet,
others might be able to comment!?

>Also how does one manage the run time heap.
>How does one compile programs to  support tree of frames.

I think the major cost in tree-of-frame allocation is in argument passing
and not so much in the heap allocation itself (if well done). You can't
pass arguments in registers easily (tree of frames implies parallel call).
Arguments have to be stored relative to the newly allocated frame. You also
have to pass an invisible `return pointer' so that the child knows where to
deposit result values (and what continuation to enable).

>In terms of storage space management, I find difficult to
>understand  management of tree of frames (unlike
>in stack based model,  which is simple to implement).

Nothing magic. Just need to keep track of parent/child pointers explicitly
as in any tree data structure.

>Thanks a lot

I'm sure others will have more to add...

	Thorsten von Eicken
	tve@cs.berkeley.edu
From: sheizafr@shum.cc.huji.ac.il (sheizaf rafaeli)
Newsgroups: comp.parallel
Subject: Loral's ASPRO -- info requested
Summary: Info requested on Loral's ASPRO
Date: 28 Dec 92 09:33:58 GMT
Organization: The Hebrew U. of Jerusalem, Computer Science Dep.


Anyone know of "Loral's ASPRO"?

Desperately seeking information, citation, or pointers on an
architecture for parallel computing known as Loral's ASPRO.

Any lead would be appreciated! Thanks in advance,

Sheizaf Rafaeli
Hebrew University of Jerusalem
Mt. Scopus, Jerusalem, Israel 91905

Tel: 011 972 (0)2 883106     E-mail: sheizafr@shum.cc.huji.ac.il
Fax: 011 972 (0)2 322545         or: sheizaf@pluto.cc.huji.ac.il
Newsgroups: comp.parallel
From: kaminsky-david@CS.YALE.EDU (David Kaminsky)
Subject: Re: Linda / The Parform
Organization: Yale University Computer Science Dept., New Haven, CT 06520-2158
Date: 21 Dec 1992 14:24:32 -0500

> We have compared the open domain Linda implementation POSYBL with a
> Transputer Multicluster, PVM and our platform The Parform. POSYBL turned
> out to be clearly worse than the other systems. Thus, we concluded, that
> the tuple space concept is inefficient.

> After time has passed now, we could make SCA-Linda measurements with an
> explicit heat equation solver on a 2D grid in our network:

	I'd like to thank Volker and Clemens for posting this data.  It
is informative to see a clear comparison of different models of
parallelism.  As we've often argued, Linda is as efficient as message
passing systems.  This data supports our view.

> For further information, we refer the reader to our old report, ftp-able
> from claude.ifi.unizh.ch. An upgraded version will be published in near
> future.

	I would also like to recommend this paper.  It contains some
interesting work on automatic load balancing.

> This code is message passing code and not Linda flavored code. Runtimes
> of a Linda flavored code were several times longer than the message
> passing style code.

	I think this statement is misleading.  I examined the "Linda
flavored" code.  It approaches a domain decomposition problem using
dynamic tasking.  The worker process repeatedly grabs a column
(or a block of columns), gets the columns bordering it, updates
the column, and returns the column to tuple space.

	The fact that Linda makes it easy to write this sort of
program doesn't mean that Linda programmers use this approach blindly
without regard to the problem.  In this case, no decent Linda
programmer would ever consider doing it this way.

	The proper way to write the code is to statically allocate
blocks of the matrix to the workers and have the workers exchange
border columns at each iteration.  This is the "message passing code"
to which they refer.  

	Linda is a superset of message passing and, as this data
demonstrates, no less efficient than message passing systems on
message passing problems.  It can handle both message passing codes
(as this one clearly is) and codes not easily handled by message
passing systems (e.g. those containing shared variables).
Characterizing a code as "linda flavored" or "message passing"
shortchanges Linda's flexibility.

	For more information about Linda applications, I refer the
reader to "Experience with Linda", Bjornson, et al. (YALEU/DCS/TR-866)
and Rob Bjornson's Thesis (1992).  Both are available from Chris
Hatchell (hatchell@cs.yale.edu).





Newsgroups: comp.parallel
From: parallel@netcom.com (B. Mitchell Loebel)
Subject: The PARALLEL Processing Connection - January Meeting Notice
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Thu, 31 Dec 1992 05:24:55 GMT

January 11th - Embedded Parallel Systems and Other Entrepreneurial 
Opportunities

PPC's 1993 agenda will feature increased emphasis on entrepreneurship 
and workstation level parallelism.  We start off the new year with a 
presentation on embedded parallel systems and a look at foreign 
entrepreneurs seeking connections in the U.S.

Our January speaker is Craig Lund, president of Local Knowledge.  
Craig is one of the world's leading experts on the market for embedded, 
parallel systems and is also a well regarded authority on the market for 
parallel database systems.  This will be an ideal opportunity for 
attendees to obtain expert advice on their new product ideas.

Craig assists overseas clients in establishing their parallel processing 
products in North American markets by producing custom market 
research reports to identify appropriate market niches; in addition, he 
often seeks U.S. technical and marketing partners for them.  Local 
Knowledge can also manage a client's North American product rollout.

PPC hopes to learn early of new products and business opportunities 
from Craig; we stand available as a resource of technical and marketing 
talent for him.

The meeting will take place at 7:30 PM at Sun Microsystems at 901 
South San Antonio Road in Palo Alto, California. Southbound 
travelers exit 101 at San Antonio; northbound attendees also exit at San 
Antonio and take the overpass to the other side of 101. There is an $8 
visitor fee for non-members and members ($40 per year) will be 
admitted free.

Please be prompt; we expect a large attendance; don't be left out or 
left standing.

For further information contact:

-- 
B. Mitchell Loebel                                      parallel@netcom.COM
PARALLEL Processing Connection                                 408-732-9869

Newsgroups: comp.parallel
From: jr@ksr.com (John Robinson)
Subject: Re: BBN Monarch
Organization: Kendall Square Research, Waltham, MA
	<1992Dec15.134558.7762@hubcap.clemson.edu>
	<1992Dec16.134859.20701@hubcap.clemson.edu>
	<1992Dec18.133247.10850@hubcap.clemson.edu>
	<1992Dec23.140915.21492@hubcap.clemson.edu>
Date: 30 Dec 92 17:51:53 EST


In article <1992Dec23.140915.21492@hubcap.clemson.edu> gottlieb@allan.ultra.nyu.edu (Allan Gottlieb) writes:

   In article <1992Dec18.133247.10850@hubcap.clemson.edu> jkenton@world.std.com (Jeff Kenton) writes:

      gottlieb@allan.ultra.nyu.edu (Allan Gottlieb) writes:

      The TC-2000 was a real product.  We thought we did a good job on it, but
      it turned out to be difficult to find a market niche for.

   I think perhaps I wasn't clear.  I know for sure the TC2000 was a real
   product.  We have used one to test some coordination algorithms on a
   different (but similar) architecture from our own ultra.  What I
   wasn't sure about was my assertion that monarch was viewed as having a
   large research component and not planned to lead directly to a product.

The April 1990 article in IEEE Computer [Rettberg at al, "The Monarch
Parallel Processor Hardware Design"] makes the distinctions pretty
clear.  As for its research nature, the article states (p. 19):

"Supported by the DARPA Strategic Computing Program, we began
developing the Monarch parallel processor in 1985. ... We are
currently seeking support to finish the implementation."

There are also indirect hints in the article concerning tradeoffs in
the design that suggest how near or far it came to being a product.
Two of four custom chips were designed, one fabricated at MOSIS.  The
I/O happens over 4-wire paths to some of the processors; how these are
mated to disks is not specified.  The packaging design was expected to
change as the design evolved.

I'd say your assertion is pretty accurate.  Does the same hold for the
ultracomputer?
--
/jr, aka John Robinson                       Place stamps here
internet: jr@ksr.com                    Post Office will not deliver
uucp: {world,harvard,uunet}!ksr!jr      mail without correct postage

Newsgroups: comp.parallel