HDTenEightyP/NetNews huggingface dataset:
From: sc131109@seas.gwu.edu (Harmel K. Singh)
Subject: ++++++++++++++ Info on Massively parallel Machines
Apparently-To: uunet!comp-parallel
Originator: sc131109@seas.gwu.edu
Organization: George Washington University
Distribution: usa
Date: Wed, 8 Apr 1992 22:07:38 GMT


Hello ,

I would be obliged if somebody gave me info on the following
Massively Parallel machines.
Please let me know of articles, books, manuals etc which describe there 
architectures.

Machines are -
BB & N GP100
INTEL iPSC/2 VX
N CUBE 10
Amatek 2010
Connection Machine
Meiko Computing Surface

all responses will be highly appreciated.

Thank You,

Harmel Singh
Email - sc131109@seas.gwu.edu
=======================================================================

Newsgroups: comp.parallel,comp.programming
From: pelegrin@geocub.greco-prog.fr (Francois PELLEGRINI)
Subject: Re: Raytracing on a CM
X-Envelope-To: hypercube@hubcap.clemson.edu
Organization: GRECO Programmation du CNRS & LaBRI - Bordeaux,France
Date: 13 Apr 92 13:18:39 GMT


In article <1992Apr6.152259.21385@hubcap.clemson.edu> MXD120@psuvm.psu.edu (Beaker) writes:
>I have a friend who has access to a Connection Machine and we were
>thinking of compiling a raytracer on it (DKB or Rayshade) to create
>frames for animation.  I know that the code has to be optimized to
>run on a parallel machine, but I'm not sure how to do this.  Has
>anybody out there done this?  The most logical way, to me at least,
>of accomplishing this would be to send each line to a different
>processor.  Any ideas?


	Argh! The CM-2 is a SIMD machine. It implies that all processors must
do the same thing at the same time. As the ray trees will be quite different
from one pixel to another, (not even speaking of texture and shadow rays
computation), you will be in BIG trouble.
	Furthermore, as DKB is sequential, recompiling it will give you NO
optimization since it will just run on the front-end machine, not on the
CM processors.

	An idea may be to convert your processors into ray-processing
entities, picking rays into their own queues at the same time, eventually
doing nothing if their queue is empty. This amounts to splitting the
rendering equation and adding small contributions to each pixel as rays are
processed. Since you still cannot compute textures, you may have to read them
from bitmaps. Good programming job anyway...	8^}

								f.p.

-------------------------------------------------------------------------------
|   Zeu<FP> : The craziest programmer in France  |         _________          |
|------------------------------------------------|     /   |        \   \     |
| Francois Pellegrini is :                       |    /    |__   ___/    \    |
|        pelegrin@geocub.greco-prog.fr           |    \    |     |       /    |
|         pelegrin@prof.greco-prog.fr            |     \   |     |      /     |
|                                                |                            |
-------------------------------------------------------------------------------

Newsgroups: comp.parallel
From: CONNOLLY@UKCC.UKY.EDU (John Connolly)
Subject: adenart?
Organization: UNIVERSITY OF KENTUCKY
Date: 16 Apr 92 16:17:36 GMT


Seeking information on the adenart parallel processor by Matsushita.
It is advertised as a 256-processor machine with a peak perfomance
of 20 Gigaflops.

Q: Is it real or tba?

-j
From: pjn@mimsy.cs.umd.edu (P. J. Narayanan)
Newsgroups: comp.parallel
Subject: Re: Fast window summation on a SIMD machine
Date: 15 Apr 92 20:10:41 GMT
Reply-To: pjn@cs.umd.edu
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742



-    I am looking for an idea for a high-performance algorithm for
-    the following problem:
-
-	I have a large SIMD machine (maspar) with an image distributed
-	across the 2-dimensional array of processors.  Each processor has
-	a small (8*8), square piece of the image.  I want to produce a new
-	image in which the new pixels represent the sum, in the original
-	image, of a large (64*64) window around that pixel.  


	I don't know if I am stating something obvious to everyone,
but there is a simple way that I haven't come across in any books
(perhaps due to its simplicity) of achieving something close to the
above if each processor contains a single pixel (finding the
sum of a WxW window around each pixel).

	Compute the left to right prefix sums of the pixel value for
each row (using a parallel prefix). Now, each pixel receives the
prefix sums from the two ends of the W-long window in its row. (i.e.,
pixel in col N receives the sums from pixel in col N + W/2 and in col
N - W/2 - 1 in its row). The difference between these gives the sum of
W-interval in its row. Performing the same computations across the
columns, one is left with the required sum of the WxW window around
each pixel. The operation takes 2 parallel prefixes, 4 communications,
and 2 subtractions. The W/2-wide band at the borders might need
special handling, though.

	I can't give an easy way of adapting this procedure when each
PE contains a wxw window of the image, but I think it can be done.


P J Narayanan
From: jps%samay@uunet.UU.NET (Jaswinder Pal Singh)
Newsgroups: comp.parallel
Subject: Re: parallel fast multipole method
Keywords: multipole, molecular dynamics
Date: 6 Apr 92 21:11:46 GMT
Reply-To: jps%samay@uunet.UU.NET (Jaswinder Pal Singh)
Organization: Stanford University
Apparently-To: comp-parallel@uunet.uu.net

In article <1992Apr6.152353.21846@hubcap.clemson.edu>, banshee@cats (Wailer at the Gates of Dawn) writes:
>	Parallel Version of the FMM
>	Computers Math Applications
>	20,7 63 (1990)

>	Implementing the FMM in 3D
>	KE Schmidt  MA Lee
>	J Stat Phys
>	63, 1223 (1991 June)
>
>	Fast Algorithm for Particle Simulations
>	Greengard  Rokhlin
>	J Comp Phys
>	73, 325  (1987)
>
>	I've seen very little actual use of the FMM, most of the above is 
>benchmarking and algorithm proofs.  There are some MIT and Yale tech reports
>that I've not been able to get copies of as yet.  Please post or mail if there
>are some application-based papers on the FMM that I've missed.
>
>-- 
>The Wailer at the Gates of Dawn              | banshee@cats.UCSC.EDU       |
>Just who ARE you calling a FROOFROO Head?    |                             |
>DoD#0667  "Just a friend of the beast."      | banshee@ucscb.UCSC.EDU      |
>2,3,5,7,13,17,19,31,61,89,107,127,521,607....| banshee@ucscb.BITNET        |

I just saw this message and not the one that apparently preceded it, 
so this reply may not be appropriate.  

We have implemented an parallel version of the *2-d* *adaptive* fast 
multipole method (in a galactic simulation) for a shared address space m
achine, and have obtained very good speedups with it on the Stanford DASH 
multiprocessor.  A brief description of our work has been submitted for 
publication as part of a larger paper (which you can get from me) and a 
fuller paper is in the works.

Cheers,

JP
From: CONNOLLY@UKCC.UKY.EDU (John Connolly)
Newsgroups: comp.parallel
Subject: adenart?
Date: 16 Apr 92 16:17:36 GMT
Organization: UNIVERSITY OF KENTUCKY


Seeking information on the adenart parallel processor by Matsushita.
It is advertised as a 256-processor machine with a peak perfomance
of 20 Gigaflops.

Q: Is it real or tba?

-j
Newsgroups: comp.parallel
From: leech@cs.unc.edu (Jon Leech)
Subject: Re: parallel fast multipole method
Keywords: multipole, molecular dynamics
Organization: UNC-Chapel Hill Computer Science
Date: 8 Apr 92 21:01:32 GMT


In article <1992Apr6.152353.21846@hubcap.clemson.edu>, banshee@cats.UCSC.EDU (Wailer at the Gates of Dawn) writes:
>	I've seen very little actual use of the FMM, most of the above is
> benchmarking and algorithm proofs.

    Is this due to a large constant factor, because people haven't yet
spent the effort to work it into their codes, or some other cause?
--
    Jon Leech (leech@cs.unc.edu)    __@/
    "Student Activism 1968-69 Oct 23: 15 students picket the Circus
     Room to protest the poor quality of UNC sandwiches."
	_The Daily Tar Heel_, 11/15/89

Newsgroups: comp.parallel
From: rminnich@super.super.org (Ronald G Minnich)
Subject: Re: Atomic read/writes to memory in SMMs
Apparently-To: uunet!comp-parallel
Organization: Supercomputing Research Center (Bowie, MD)
Date: Mon, 13 Apr 1992 00:57:35 GMT

In a discussion on atomic writes/reads of 32-bit data to a memory, 
i.e. not splitting it up into 16-bit chunks:

>](yours truly) foolishly wrote:
>]oh, i see now. Well, if anyone out there can think of a multiprocessor, 
>]BUILT AFTER 1980 ...

In article <1992Apr8.222145.4896@alliant.com> tj@alliant.com (Tom Jaskiewicz) writes:
>The FX/8 was announced in 1985.

and Ken reminded me that the Butterfly 1 counts too. 

So far, two commercial MPs from the mid-80s had this problem. Wow.
This all seems much farther back than 1985 ... time flies.
ron
p.s. Never ask the net to prove you wrong :-)
p.p.s. Do we get to have this problem all over again with 'long long i' ?

Xref: sparky comp.parallel:1281 comp.programming:882
From: kcollins@convex.com (Kirby L. Collins)
Newsgroups: comp.parallel,comp.programming
Subject: Has anyone read Green "Parallel Processing for Computer Graphics"?
Date: 14 Apr 92 15:08:55 GMT
Organization: Engineering, CONVEX Computer Corp., Richardson, Tx., USA

I just got the latest MIT Press flyer, and it describes a book by
Stuart Green titled "Parallel Processing for Computer Graphics".
According to the blurb it "provides background information on both
computer graphics and parallel computers and then goes on to 
describe how a distributed memory multiprocessor can be used to
effectively implement the ray tracing algorithm."

Anyone read a copy of this book yet?
Newsgroups: comp.parallel,comp.programming
From: eugene@nas.nasa.gov (Eugene N. Miya)
Subject: Re: Raytracing on a CM
Apparently-To: comp-parallel@ames.arc.nasa.gov
Organization: NAS, NASA Ames Research Center, Moffett Field, CA
Date: Tue, 14 Apr 92 23:29:06 GMT

In article <1992Apr14.123255.7379@hubcap.clemson.edu> rthomson@dsd.es.com
(Rich Thomson) writes:
>the words "parallel" and "distributed".  Somewhere there was a
>parallel graphics bibliography available on the net (I can't remember
>where) and about 90% of the work was on distributing a ray-tracer.

It is integrated into the biblio.

>In article <1992Apr13.181859.4155@hubcap.clemson.edu>
>	pelegrin@geocub.greco-prog.fr (Francois PELLEGRINI) writes:
>>	Argh! The CM-2 is a SIMD machine. It implies that all processors must
>>do the same thing at the same time. As the ray trees will be quite different
>>from one pixel to another, (not even speaking of texture and shadow rays
>>computation), you will be in BIG trouble.

Same thing?  Not quite.
SIMD computing/programming only means you will learn about masking
and other operations.  The vector world learned how to deal with this
over a decade ago.  On to more difficult problems. ;^)

--eugene miya, NASA Ames Research Center, eugene@orville.nas.nasa.gov
  Resident Cynic, Rock of Ages Home for Retired Hackers
  {uunet,mailrus,other gateways}!ames!eugene
This is the Usenet: do you expect anything other than gross generalizations?
Ref: Mathematics and Plausible Reasoning, vol. 1, G. Polya

Xref: sparky comp.parallel:1282 comp.programming:883
From: leo@nas.nasa.gov (Leo Dagum)
Newsgroups: comp.parallel,comp.programming
Subject: Re: Raytracing on a CM
Date: 14 Apr 92 20:24:59 GMT
Organization: NAS, NASA Ames Research Center, Moffett Field, CA
Apparently-To: comp-parallel@ames.arc.nasa.gov

In article <1992Apr14.123255.7379@hubcap.clemson.edu> rthomson@dsd.es.com (Rich Thomson) writes:
>>In article <1992Apr6.152259.21385@hubcap.clemson.edu>
>	MXD120@psuvm.psu.edu (Beaker) writes:
>
>In article <1992Apr13.181859.4155@hubcap.clemson.edu>
>	pelegrin@geocub.greco-prog.fr (Francois PELLEGRINI) writes:
>>	Argh! The CM-2 is a SIMD machine. It implies that all processors must
>>do the same thing at the same time. As the ray trees will be quite different
>>from one pixel to another, (not even speaking of texture and shadow rays
>>computation), you will be in BIG trouble.
>
>Not necessarily.  Careful reorganization of the algorithms may let you
>take advantage of the CM-2.  Of course, this is just off the top of my
>head and not a statement based on a careful analysis of how well this
>problem maps to the CM architecture.
>
>							-- Rich

Raytracing on the CM-2 does require a substantial restructuring of the
algorithms.  It has been done though, look up:

Crow, F.C., Demos, G., Hardy, J., McLaughlin, J., and Sims, K.,
"3D Image Synthesis on the Connection Machine",
Proceedings of the Conference on Scientific Applications of the Connection
Machine, Sept 12-14, 1988, pp. 260-281.

There are probably other references that I don't know about.

Leo Dagum
NASA Ames
Newsgroups: comp.parallel
From: oudelutt@cs.utwente.nl (Paul Oude-Luttighuis)
Subject: Looking for recent papers on parallel lexing/parsing
Apparently-To: comp-parallel@uunet.uu.net
Originator: oudelutt@utis142
Organization: University of Twente, Dept. of Computer Science
Date: Mon, 6 Apr 1992 10:08:43 GMT


   Dear readers of this newsgroup,

  I am looking for the text of two papers presented at the 6th 
  International Parallel Processing Symposium (Berverly Hills, CA, 
  USA, March 23--26, 1992).  The proceedings have, of course, not 
  appeared yet at our library.  Still, I would like to read them 
  quickly in order to be able to include them in a soon to appear 
  annotated bibliography on parallel parsing.  Is there any way to 
  get the text of the following two papers quickly (maybe via the 
  authors themselves)?

    C.R. Asthagiri & J.L. Potter
    Associative parallel lexing

    W. Deng & S. Sitharama Iyengar
    Parallel algorithms for arithmetic expression parsing

  Thanks!

  Paul Oude Luttighuis
  Dept. of Computer Science
  University of Twente
  P.O. Box 217
  NL-7500 AE  Enschede
  The Netherlands

Newsgroups: comp.parallel
From: tj@alliant.com (Tom Jaskiewicz)
Subject: Re: Atomic read/writes to memory in SMMs
Organization: Alliant Computer Systems Corp.
Date: Wed, 8 Apr 1992 22:21:45 GMT

In article <1992Apr6.230404.4322@hubcap.clemson.edu> kweber@Snake.mcs.kent.edu (Ken Weber) writes:
>What I am referring to is the ability for a 32-bit value to be either written
>or read atomically from a memory location.  I could envision the situation
>where a read/write may work with only 16 bits of a value at a time.  This
>could lead to the following situation:
>
>Process 1 writes to low 16 bits of location A
>Process 2 writes to low 16 bits of location A
>Process 2 writes to high 16 bits of location A
>Process 1 writes to high 16 bits of location A

This exact problem could occur in the Alliant FX/8.  An FX/8 could
contain up to 8 CE processors and up to 12 IP processors.  The CE's
could do atomic reads and writes of 64 bits at a time.  The IP's were
powered by Motorola 68012's and could only do atomic reads and writes of
16 bits.

User code rarely had a problem with this.  Most multiprocessing with
shared memory by user code was done only on CE's.  However, the
CONCENTRIX kernel had nearly all of its data structures in memory shared
by all the CE's and IP's.  The situation you describe above not only
could occur, it DID occur.  (It caused some very strange bugs).

In article <1992Apr7.113842.26166@hubcap.clemson.edu> rminnich@super.super.org (Ronald G Minnich) writes:
]oh, i see now. Well, if anyone out there can think of a multiprocessor, 
]BUILT AFTER 1980 ...

]But, for your case Ken, I think it safe to assume that 32-bit
]writes are atomic. 
]
]someone want to show me wrong?

The FX/8 was announced in 1985.
-- 
##########################################################################
# The doctrine of nonresistance against arbitrary power, and oppression is
# absurd, slavish, and destructive of the good and happiness of mankind.
#   -- Article 10, Part First, Constitution of New Hampshire

Newsgroups: comp.parallel
From: jab@cs.duke.edu (John A. Board)
Subject: Re: parallel fast multipole method
Summary: parallel implementation of 3-D fast multipole algorithm
Keywords: multipole, molecular dynamics
Organization: Duke University Computer Science Dept.; Durham, N.C.
Date: 9 Apr 92 16:50:24 GMT


In article <1992Apr2.132157.8808@hubcap.clemson.edu>, figuei@caladan.rutgers.edu (Francisco Figueirido) writes:
> 
> 
> Hi! I am interested in finding documentation about the fast multipole method
> applied to the calculation of interaction forces, either in an astrophysical
> or molecular dynamics context, specially parallel implementations. I will
> appreciate any pointers ... Thanks!
>
We (at Duke) have implemented the three dimensional fast multipole method on
five or six different parallel computers and/or distributed environments
(i.e. Linda, PVM) and have had good success with it; we have a uniprocessor
cross-over point (where FMM is more efficient than brute force Coulomb or
gravitational summation) of about 3000 particles, and we obtain 
more or less linear speedup on modestly sized (<= 32 processor) parallel
systems.  In collaboration with the Univ. of Illinois we have incorporated 
our code into a molecular dynamics program and are getting good improvements 
in uniprocessor simulation time (factors of 10) on large molecules and 
additional speedups from parallelism.  

Anyone who would like more information can email me for a copy of our
tech reports on this (only a brief description of the MD work is available
at the moment). email address is jab@ee.egr.duke.edu


 
-- 
John Board                                   INET: jab@ee.egr.duke.edu
Assistant Professor                            or  jab@duke.cs.duke.edu
Dept. Electrical Eng'g and Dept. Comp. Sci.  FAX:   +1 (919) 660-5293
Duke University, Durham NC 27706 USA         VOICE: +1 (919) 660-5272
From: br@cs.cmu.edu (Bill Ross)
Newsgroups: comp.parallel
Subject: Fast window summation on a SIMD machine
Date: 14 Apr 92 18:02:25 GMT
Reply-To: br@cs.cmu.edu
Organization: CMU Vision and Autonomous Systems Center


    I am looking for an idea for a high-performance algorithm for
    the following problem:

	I have a large SIMD machine (maspar) with an image distributed
	across the 2-dimensional array of processors.  Each processor has
	a small (8*8), square piece of the image.  I want to produce a new
	image in which the new pixels represent the sum, in the original
	image, of a large (64*64) window around that pixel.  

	Currently, I copy the large window of pixels onto each processor from
	the surrounding processors and then perform an efficient window
	summation algorithm without having to do any further communication.
	This is very inefficient because each processor is duplicating many
	of the additions of its neighbors.

	Any ideas?  Pointers to published references?

    Thanks!
    Bill Ross
    br@cs.cmu.edu 
Xref: sparky comp.parallel:1246 comp.programming:748
From: MXD120@psuvm.psu.edu (Beaker)
Newsgroups: comp.parallel,comp.programming
Subject: Raytracing on a CM
Date: 3 Apr 92 23:04:49 GMT
Organization: Penn State University

I have a friend who has access to a Connection Machine and we were
thinking of compiling a raytracer on it (DKB or Rayshade) to create
frames for animation.  I know that the code has to be optimized to
run on a parallel machine, but I'm not sure how to do this.  Has
anybody out there done this?  The most logical way, to me at least,
of accomplishing this would be to send each line to a different
processor.  Any ideas?

Matthew "Beaker" Donadio      / INCLUDE "disclaimer.dat"
Penn State                   /
mxd120@psuvm.psu.edu        /   OBJECT
donadio@wilbur.psu.edu     /      Disclaimer
Newsgroups: comp.parallel
From: roy@netcom.com (Roy Carlson)
Subject: PARALLEL Processing Connection meeting notice
Apparently-To: comp-parallel@ames.arc.nasa.gov
Keywords: meeting
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Distribution: na
Date: Tue, 07 Apr 92 12:24:02 GMT


PARALLEL Processing Connection meeting notice --

Technology transfer -- always an important issue for the national 
laboratories is especially significant in this day of defense cutbacks and 
economic recession. Senior staff members of Lawrence Livermore have 
agreed to show us some of the lab projects which are presently available for 
licensing into the private sector. Tony Bernhardt will talk about laser 
pantography for multi-chip module packaging; Tony DeGroot will discuss 
his SPRINT systolic array processor and the application software that 
Livermore has ported to it. These and other technologies are available for 
license and cooperative research with the Livermore Labs. Given the 
economic pressures, we should see some excellent entrepreneurial 
opportunities.

The meeting will take place at 7:30PM on April 13th at the NeXT 
Corporation at 123 Saginaw Drive in Redwood City. This is one mile east  
of the Seaport Boulevard exit off 101, left onto Chesapeake Drive and then 
the second left onto Saginaw.

Please be prompt; as usual, we expect a large attendance; don't be left out or 
left standing. There is a $8 fee for non-members and members are admitted 
free.

-- 
B. Mitchell Loebel                                      parallel@netcom.COM
PARALLEL Processing Connection                                 408-732-9869
From: ian@spider.co.uk (Ian Heavens)
Newsgroups: comp.parallel
Subject: Multiple Readers/Single Writers Lock
Date: 7 Apr 92 10:26:45 GMT
Organization: Spider Systems Limited, Edinburgh, UK
Apparently-To: comp-parallel@uunet.uu.net

I'm looking for references or implementations of an efficient
spin-lock based scheme for multiple-reader/single-writers locking.

I'd be interested in

1. a scheme which queues a writer behind all current readers. 
2. a cheaper scheme with possible writer starvation
3. efficient implementations on 80386 hardware.

This must be a well trodden path, but the only implementations I've found
are semaphore based, and the in environment in question all critical sections
are short.

Thanks for any tips,

ian



---
Ian Heavens				ian@spider.co.uk                 
Spider Systems Ltd			
Spider Park, Stanwell Street		
Edinburgh, EH6 5NG, Scotland		+44 31 554 9424 (Ext 4166)
--
From: yariva@gemini.math.tau.ac.il (Aridor Yariv )
Newsgroups: comp.parallel
Subject: hardware support for fine-grained comp.
Date: 14 Apr 92 16:17:46 GMT
Organization: Tel-Aviv University Math and CS School, Israel
Apparently-To: comp-parallel@uunet.uu.net
Originator: yariva@gemini.math.tau.ac.il




I am working on a parallel language which combines functional and object 
oriented subsets. In general the implementation is based on light-weight tasks
which as usual, causes overhead (in every processor) due to their
allocation/scheduling/context-switch.

I am looking for references on SPECIAL HARDWARE FEATURES which helps to overcome
this local overhead like : 

1. co-processors/hardware which prepare (IN PARALLEL) the next task(process) in the 
   queue for work (Make ready the relevant data in registers). 

2. Special machine instructions. 

Are there any articles on this subject ? 

Thanx for the cooperation.

	- Yariv Aridor
	  E-mail:yariva@math.tau.ac.il

paper address:

Yariv Aridor
Computer Science Dept.
Tel-Aviv university
Ramat-Aviv
Tel-Aviv 69978
ISRAEL
Newsgroups: comp.parallel,comp.arch,sci.math.num-analysis
From: ugurdag@ces.cwru.edu (Fatih Ugurdag)
Subject: Looking for Dr. T. C. Hu...
Apparently-To: comp-parallel@uunet.uu.net
Keywords: Scheduling
Organization: Computer Engineering and Science, Case Western Reserve University
Date: Fri, 17 Apr 92 08:06:44 GMT

Hi

I am looking for the address and phone number of Dr. T. C. Hu. I am
really desperate to get in touch with him, regarding one of his papers
that he wrote in Operations Research Journal, 1961.

I would appreciate any help in this regard.

Thanks in advance.




-- 
Fatih Ugurdag
Case Western Reserve University

Newsgroups: comp.parallel,comp.theory